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N el mundo de los ordenadores personales los 
lenguajes de programación que se disputan 
el primer puesto son, prácticamente, sólo dos: 
el popularísimo BASIC y el más aristocrático 
Pascal, 

A decir verdad, en el segmento de los mi¬ 
croordenadores profesionales, para entender¬ 
nos, aquellos que están dotados del sistema 
operativo CP/M (en las máquinas de 8 bits) 
o MS DOS (máquinas de 16 bits) encontramos también otros len¬ 
guajes, bien conocidos en la informática tradicional, como el FOR¬ 
TRAN o el COBOL, dedicados el primero a la programación cien¬ 
tífica y el segundo a la de gestión. Incluso se ha llegado a intro¬ 
ducir en el PC IBM el ya venerable RPG II, lenguaje sin duda in¬ 
teresante de tipo "no de procedimiento 1 ’, es decir, que el progra¬ 
mador define las especificaciones del problemas más que las ins¬ 
trucciones específicas; se puede considerar que en él la lógica 
de control queda sobrentendida por lo menos a grandes rasgos. 
Está orientado, por su propia naturaleza, al tratamiento de datos 
por "lotes” (en inglés "batch”), es decir, en grandes masas conse¬ 
cutivas. ¿Puede haber algo más extraño al auténtico espíritu -—in¬ 
teractivo, transaccional y en tiempo real— del ordenador perso¬ 
nal? Para quien no conozca estos términos, recordamos que se re¬ 
fieren, respectivamente, al diálogo hombre-sistema, al tratamiento 
esporádico de datos únicos y a la inmediatez de los resultados 
(esto, naturalmente, si es que la lentitud de ciertos intérpretes BA¬ 
SIC lo permite). 

Con las herramientas de programación mencionadas (COBOL, 
FORTRAN y RPG) se ha realizado el reciclaje del enorme volu- 
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men de software creado en los años sesenta y setenta con una 
cierta facilidad. Este software se creó para ordenadores grandes 
y miniordenadores, especialmente en el campo comercial para 
contabilidad, facturación, almacenaje y demás grises pero útiles 
aplicaciones, Y es una pena porque este proceso quizá haya im¬ 
pedido a bastantes programadores ponerse al día y concentrar 
sus esfuerzos en las nuevas aplicaciones para ordenadores per¬ 
sonales: gestión de bases de datos descentralizadas, hojas elec¬ 
trónicas ("spreads heet") y, ¿por qué no?, inteligentes juegos com¬ 
puterizados. 

Pero no divaguemos más y volvamos a los ordenadores per¬ 
sonales "de verdad". Dos son, fundamentalmente, los motivos que 
hacen del BASIC y del Pascal los lenguajes más adecuados a este 
nuevo espíritu. 

• la tnteractividad, 

• l.i sencillez y la rapidez de uso. 

Para ser exactos, la primera virtud es más propia del plebeyo 
BASIC que del noble Pascal, y está ligada principalmente al ca¬ 
rácter interpretativo del primero, aunque hay que recordar que 
también existen BASIC compilados. Gracias a la interpretación, es 
decir, a la traducción directa durante la ejecución, característica 
común también al LOGO y demás esotéricos lenguajes, como el 
FORTH y el APL, es posible probar rápidamente un programa 
sin problemas ni complicaciones. En cambio, el Pascal es com¬ 
pilado, lo que comporta el uso de multitud de herramientas: un 
editor para redactar los programas, un enlazador-cargador 
("linkoi leader") para conjuntarlos y cargarlos en el área de traba¬ 
jo y mi compilador para traducirlos al lenguaje máquina. 

I !n honor a la verdad, en ciertas implementaciones del Pascal 
t|in< parten del excelente UCSD Pascal, realizado por el profesor 
Howles, de la Universidad de San Diego, en California (UCSD sig¬ 
uí 1 1 o, i precisamente University of California at San Diego) se ha he- 
elio mi gran trabajo de simplificación para hacer más fáciles y cla¬ 
ma o.Mlau aburridas operaciones. Sin embargo, queda el hecho de 
gil" la raso de edición, independiente de la de compilación, sigue 
lili *111 lo un mal necesario, con el agravante, además, de tener que 
i. Illi.ii ol programa desde el principio cada vez que el compi¬ 

la. |. ii i lé un error de sintaxis (también en BASIC "syntax error" es 
un iii<-usaje que sale cada que vez que se viola alguna regla 
- -lili- |i .ilion, pero no es necesaria ninguna maniobra para cambiar 
de "ambiente", dado que siempre se permanece en un mismo 
y i'iiiI- i entorno), 

Además, algunos críticos autorizados han llegado a sostener 
. 111 ) 11111 < * no compartimos plenamente su extremismo— que "... la 


reintroducción de la compilación en el ámbito de los ordenado¬ 
res personales realizada por el Pascal... ha sido un error". 

¿Por qué hablar entonces de programación estructurada, ba¬ 
sándose en el Pascal en un libro de divulgación principalmente 
dirigido al usuario final? Pues porque el Pascal posee por lo me¬ 
nos una virtud definitiva que el BASIC ni siquiera puede soñar: 

La estructuración 

Es decir, un planteamiento formal claro y riguroso inspirado 
en los más modernos y sanos principios del arte de la progra¬ 
mación. 

Los consabidos críticos autorizados tildan al BASIC de 
lenguaje "barullo”, con las pésimas costumbres del vetusto 
FORTRAN (el COBOL, en cambio, ya les resulta más presentable, 
pues tiene una cierta pinta de lenguaje semiestructurado...), tan es 
así que hoy día en la mayoría de nuestras universidades no 
se enseña más que Pascal y un poco de FORTRAN, mientras que 
el extendidísimo BASIC queda olvidado, con el consiguiente 
peligro, también es verdad, de formar informáticos aspirantes al 
desempleo, dado que no saben programar ni en BASIC ni en 
COBOL. Pero esto es otro tema, y, si en todo caso, la programa¬ 
ción estructurada no tiene ninguna culpa, ni con ello se menoscaba 
su excelente capacidad pedagógica y formativa. 

Efectivamente, el Pascal fue ideado originariamente con fina¬ 
lidades didácticas. El padre de este lenguaje, el suizo Niklaus 
Wirth, profesor del Instituto Politécnico de Zurich (que además ha 
presentado recientemente una nueva versión, expresamente mo¬ 
dular, denominada Modula 2), siempre ha declarado qye se con¬ 
sidera esencialmente un docente. En consecuencia, el Pascal, en 
alguna de sus implementaciones, no está ni siquiera dotado de op¬ 
ciones adecuadas para la gestión de archivos sobre memorias de 
acceso aleatorio (disco) mientras que, sin embargo, el "basto" 
BASIC posee por lo menos aquellas funciones necesarias para la 
vida cotidiana. 

Hacer mención de esta y otras carencias, como, por ejemplo, 
la ausencia, aunque solamente en el Pascal estándar de Wirth, de 
variables tipo cadena, casi imprescindibles en la manipulación de 
datos alfanuméricos, no significa querer dar pie a la polémica, y 
aún menos desanimarles de la lectura de los capítulos siguientes. 
Nuestro interés es que muchos usarios convencidos del BASIC, 
que perseveran en el vicio de añadir desaforadamente líneas a 
los programas, preocupándose únicamente de que éstos cortan 
(lo que acaba ocurriendo después de pasar infinitas penalidades, 
siempre proporcionales a la prisa con la que se escribe la prime- 
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ra versión), aprovechan una buena ocasión de aprender por lo me¬ 
nos reglas de buen estilo. Y no sólo esto. 

En efecto, los cánones de la programación estructurada pue¬ 
den resumirse en los tres siguientes: 

• definir una serie de construcciones estándar sobre las que 
articular, por bloques, la totalidad del programa; 

0 subdividir un problema complejo en subproblemas más 
sencillos (principio de "divide y vencerás"). Se traduce 
en el plantamiento top-down (de arriba a abajo) de los pro¬ 
gramas; 

0 determinar una tipología y unas estructuras de datos ade¬ 
cuadas para el problema considerado. 

Aprender, y mejor si es con espíritu crítico, estos tres princi¬ 
pios le sirve a cualquiera, porque se acostumbra a trabajar de una 
forma ordenada y rigurosa que facilita enormemente la compren¬ 
sión de lo que se hace. Y esto es un aspecto importantísimo en 
especial para aquellos que trabajan profesionalmente en el man¬ 
tenimiento de software. 

Puede que oiga decir que todo lo expuesto no tiene validez 
para el BASIC, puesto que este "tosco" (aunque fácil y eficaz) 
lenguaje no posee las estructuras IF/THEN/ELSE, DO/WH1LE, 
REPEAT/UNTIL, etc., características; no haga caso. Este tipo de co¬ 
mentarios están completamente fuera de lugar, puesto que redu¬ 
cen la programación estructurada solamente a su primer aspecto, 
aquel que, en suma, es el más externo, formalista y, llevado al lí¬ 
mite, bizantino, El propio Wirth considera que la precisión formal 
es un medio, no un fin. Resulta extremadamente significativo al res¬ 
pecto el feliz título de un excelente texto de nuestro "gurú" suizo: 
"Algoritmos + estructuras de datos = programas". 

La subdivisión en módulos y la estructuración de los datos se 
revelan como el aspecto más potente y característico del estruc- 
turalismo en la programación. Y, como intentaremos demostrar en 
un próximo volumen de la BBI (programando como es debido), es¬ 
tos dos principios pueden, al menos en parte, ser emulados con 
los sencillos medios que el BASIC pone a nuestra disposición. 

Será más fácil para quienes se enamoren del Pascal (los usua¬ 
rios de este elegante lenguaje son muchísimos). Quienes perma¬ 
nezcan fieles al BASIC tendrán mucho que aprender, no pudien- 
do ignorar que existen ya, y se espera que aumente su número, 
dialectos BASIC planteados cada vez de forma más parecida al 
Pascal. 
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TOP-DOWN: PROGRAMANDO DE ARRIBA A ABAJO 


Los orígenes 




o debemos engañarnos: la programación es¬ 
tructurada desilusiona a veces, aunque quizá 
sólo en una mínima parte, a quien se "casa" 
con ella. Por eso no queremos tampoco miti¬ 
ficarla demasiado (a pesar de lo cual le tene¬ 
mos que confesar que nos encanta). 

Para hacernos una primera idea empeza¬ 
remos por una de sus más célebres peculia¬ 
ridades: la de la programación descendente 
(llamada en inglés "top-down"), que consiste en empezar analizan¬ 
do el problema en sus líneas generales, para después, poco a 
poco, dilucidar ios casos particulares. Todos los pasos, naturalmen¬ 
te, deben enlazarse de una forma perfecta, con una serie de hábi¬ 
les y precisos encajes, como si fuera un puzzle. 

La ventaja de este planteamiento reside, en primer lugar, en 
el hecho de que se ofrece una visión de conjunto, panorámica, 
más fácil de dominar Como decía uno de los máximos represen¬ 
tantes del estructuralismo, "el hombre tiene la cabeza pequeña", 
y por tanto, se cansa si tiene que dominar asuntos demasiado am¬ 
plios o complicados. Si lo pensamos bien, esto no es una nove¬ 
dad. Los dibujantes trazan desde hace siglos en hojas separadas 
las vistas de conjunto y los dibujos de detalles. Los "estructuraíis- 
tas" han tenido que hacer su guerra particular por ser la Informá¬ 
tica, en el fondo, una disciplina joven. Durante mucho tiempo (los 
malintencionados añadirán: incluso ahora, en el oscuro rincón de 
los viejos centros de elaboración de datos...) se han desarrollado 
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programas kilométricos escritos como un todo, y que tenían al fi¬ 
nal un desenvuelto 

30000 IF RESPÍ="Y" THEN BOTO 120 

Peor todavía: se han escrito programas en los cuales las con¬ 
diciones de final de ejecución estaban en un imprevisible punto 
intermedio. En estas condiciones, seguir el discurrir de un largo 
programa, especialmente si no ha sido escrito por nosotros, se 
vuelve algo realmente trágico, y comporta un continuo enrollar y 
desenrollar el listado. 


Estructuras de control y estructuras de datos 

Otra crítica de los estructuralistas al modo tradicional de es¬ 
cribir software se refiere al estilo de programación "espagnetti" 
(programas desordenados). Veamos un sencillo ejemplo en 
BASIC: 

300 IF A>B THEN 330 
310 C=B-A 

320 PRINT ft,B,C:GOTO 340 
330 C=A-B:GOTO 320 
340 (Resto del programa) 

Para ser sinceros, creemos que nos hemos "pasado 11 un poco 
con el ejemplo. De todas formas, en lenguajes como el Pascal o 
incluso en algunos dialectos del BASIC dotados de la construc¬ 
ción, IF-THEN-ELSE, la cuestión se'reduce a: 

300 IF A>B THEN C=A-B ELSE C=B-A 

310 PRINT A.B.G 

320 (Resto del programa) 

Que para quien no lo sepa, se lee de una forma así de segui¬ 
da y elocuente: si (IF) A es mayor que B, entonces (THEN) calcula 
C como diferencia entre A y B; si no (ELSE) calcúlalo como dife¬ 
rencia entre B y A. Sencillo, ¿verdad? 

Pero sigamos con el tratamiento descendente. La programa¬ 
ción estructurada quiere constituir un conjunto orgánico de reglas 
de cara a la realización de "buenos" programas. Este adjetivo, in¬ 
dudablemente genérico, se verá mejor definido, especialmente en 
los capítulos siguientes, cuando demos ejemplos concretos de 
este moderno planteamiento. Bajo una visión general, la progra¬ 
mación estructurada presenta tres aspectos: 



• sintaxis, 

• semántica 

• pragmática. 

El primero está en relación con los lenguajes concretos de 
programación que se inspiran explícitamente en principios pare¬ 
cidos: después del "progenitor" (Algol) se habla sobre todo de 
Pascal, Ada, Modula 2 y “C"; hay algunos atisbos también en 
COBOL y en algunos BASIC. 

En cuanto a la semántica, o sea, al significado de las palabras 
o al encuadramiento conceptual de las "estructuras", tenemos que 
subrayar desde ahora que, para estructurar no se deben de tomar 
sólo en cuenta, como sucede común y superficialmente, las es¬ 
tructuras de control, es decir, de gobierno del flujo de las instruc¬ 
ciones, sino también las ESTRUCTURAS DE DATOS íntimamente li¬ 
gadas a las primeras. 

La pragmática, por último, se refiere a las consecuencias prác¬ 
ticas, con prisa por materializar los "principios sagrados" en la pro¬ 
gramación de todos los días. Este aspecto enlaza, obviamente, con 
la exposición de la sintaxis del Pascal. En términos generales, la 
pragmática tiene que ver con la estructuración de la "arquitectu¬ 
ra" de un programa, centrada fundamentalmente en el desarrollo 
top-down (descendente) de los programas y de las estructuras 
dadas. 


Una gran polémica: GOTO sí, GOTO no 

El fundamento más célebre y controvertido de la.p:rograma- 
ción estructurada es el anti-GOTO, o más finamente, 'OOTO-less 
programming’', junto al "ego-less programming", es decir, ¡a pro¬ 
gramación clara para todos y bien documentada. El "GOTO-less 
programming", entendido radicalmente, significa suprimir para 
siempre la instrucción GOTO, de salto incondicional. Alguien dirá: 
¿no son los saltos la sal misma de la programación? Además, 
¿cómo se puede evitar si está prácticamente integrada con las 
operaciones de decisión (IF) y, por lo tanto, con los saltos condi¬ 
cionales? 

Para que nos entendamos mejor, hay que señalar que esta¬ 
mos hablando de lenguajes de programación de alto nivel, o sea, 
de aquellos "orientados al problema". En el lenguaje máquina los 
saltos incondicionales son inevitables (aunque hay quien está pro¬ 
yectando CPUs de arquitectura inspirada en el estructuralismo), 
pero pasando a un nivel más elevado, más cercano a nuestra ma¬ 
nera de razonar y de hablar, deberíamos poder abolidos. Respec- 
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to a la manera de hacerlo hemos visto un pequeño ejemplo en el 
programa anterior, usando la construcción ELSE. 

Entre los primeros que 1 arremetieron contra el vituperado 
GOTO está Esdger W. Dijkstra, que en 1968, en una famosa carta 
enviada a la revista de la ACM (Asociación de Cálculo Automá¬ 
tico USA), proclamó la necesidad de eliminarlo en todos los len¬ 
guajes de alto nivel que pretendieran ser dignos de este nombre. 

El título de la comunicación era como un latigazo: 'COTO con- 
sidered harmfuU", algo así como ''Ese maldito y pernicioso GOTO" 
(en traducción libre, claro). En ella vertían-duros juicios contra el 
vetusto FORTRAN (lenguaje para usos científicos) y el PL/1 (len¬ 
guaje de uso general, más moderno, pero que tuvo poco éxito): 
al primero, lo definía como "enfermedad infantil", y al segundo le 
auguraba "una muerte fatal". 

En correspondencia con el "GOTO-less”, se han desarrollado 
varios lenguajes en los cuales la instrucción GOTO no existe (por 
ejemplo, el BLIS, o, por citar otros conocidos también en los orde¬ 
nadores personales, el LOGO y el FORTH). Hay algunos, sin em¬ 
bargo, que aunque sean estructurados lo toleran: por ejemplo, el 
lenguaje C acepta frases con saltos incondicionales, y el mismo 
Pascal incluye la instrucción GOTO, a pesar de que desaconseja 
decididamente su uso. Efectivamente, además de imponer que la 
etiqueta de destino del salto se declare explícitamente (se tiene 
el equivalente de un GOTO 150 del BASIC, pero con el inconve¬ 
niente de tener que definir previamente 150 como etiqueta "la- 
bel") es habitual que en los manuales de Pascal la instrucción 
GOTO sea tratada en último lugar, como diciendo: "si verdadera¬ 
mente no sois capaces de prescindir de ella, aquí la tenéis, para 
casos extremos". 

Esta "prohibición" del GOTO le parece todavía a mucha gen¬ 
te una manía. De todas formas, como comentamos antes, no agota 

los cánones de la programación estructurada. Estos, lo repetimos 
de nuevo, son tres: 

• desarrollo descendente (top-down), 

• moduiaridad, o sea, subdivisión en pequeñas partes, 

• estructuración de los datos, además de los programas. 

Dijkstra, en "Structured programming" (texto de obligada re¬ 
ferencia, escrito junto con otros dos "magos" de la informática: Dahl 
y Hoare), hace hincapié en que para dominar un tema tan com¬ 
plejo la única esperanza consiste en la estrategia del divide et im¬ 
pera ("divide and conquer", que dicen los ingleses) Todo se re¬ 
sume en el uso disciplinado de ciertas estructuras de control que 
vamos a reseñar inmediatamente, no sin antes repetir que, des¬ 
pués de todo, deben integrarse íntimamente con estructuras pa¬ 
ralelas de datos. 


Un teorema elegante 

Tres estructuras (o construcciones) elementales son los au¬ 
ténticos modelos de pensamiento, base de una programación or¬ 
denada: 

• secuencia; 

• a la que corresponde la construcción IF-THEN- 

ELSE; 

• iteración asociada a la construcción DO-WHILE. 

Ninguna de ellas requiere una instrucción GOTO o similar. 
El soporte teórico de este conjunto es el famoso teorema de Ja- 
copini-Bóhm que demuestra que cada programa, por complejo 
que sea, puede desglosarse en las tres estructuras mencionadas 

(Fig. 1). 

Para explicarlas daremos por descontado que se conocen los 
diagramas de flujo (flow-chart), es decir, la representación gráfica 
—con rectángulos, rombos y otros símbolos análogos— de un pro¬ 
grama. De todas formas, para beneficio de ignorantes y dejados 
que no quieran repasar los anteriores volúmenes de la colección, 
recordaremos que: un bloque rectangular contiene una o más ins¬ 
trucciones, o bien expresa un subprograma, procedimiento o 










subrutina (en este caso el rectángulo suele tener dos rayas ver¬ 
ticales en los laterales), cuyo nombre será situado en su interior; 
un rombo representa un bloque de decisión; contiene en su inte¬ 
rior una pregunta o el test de una determinada condición (com¬ 
paración o similar) y tiene dos salidas, correspondientes la prime¬ 
ra a ''verdadero 1 ’ (o "SI") y, la segunda, a "falso" ( o ''NO"). 

Un bloque cualquiera puede, a su vez, resumir (es la idea del 
top-down) un conjunto de bloques más o menos intrincados en 
los que está subdividido. En la figura 1 hemos denominado A y B 
a las sentencias de los rectángulos, y D--a la decisión genérica o 
pregunta de los rombos. 

Fiémonos de Jacopini & C. y examinemos rápidamente las tres 
estructuras propuestas por ellos, una tras otra. La primera es ba¬ 
nal; corresponde sencillamente al hecho de que los programas de¬ 
rivan de la secuencia de instrucciones. La estructura de selección 
IF-THEN-ELSE ya la hemos examinado en la práctica; unida al de¬ 
sarrollo top-down, permite una visión panorámica notable. Por 
ejemplo, en un BASIC estructurado se escribirá: 

300 IF <cond> THEN GOSUB 1000 ELSE GOSUB 1500 

donde <cond> representa una condición genérica a verificar. 

Supongamos que la subrutina 1000 calcula los descuentos 
para los grandes clientes y la 1500 para los ordinarios; queda en¬ 
tonces claro lo que el programa, a grandes líneas, realiza. Antici¬ 
pemos que el Pascal, lenguaje de más alto nivel que el BASIC, ali¬ 
ña todo con una semántica más eficaz de los nombres de proce¬ 
dimiento, Tendremos así algo parecido; 

IF <CQND> THEN DE5CBRUT ELSE DESCORD 

donde "descbrut" y "descord” son, ciertamente, más elocuentes 
que los ininteligibles GOSUB del BASIC. 

Finalmente, la tercera estructura DO-WHILE. Hay que decir 
que la iteración no queda ignorada del todo por el BASIC, pues 
dispone del bucle FOR-NEXT (heredado del DO del FORTRAN). 
Aunque cómodo, no es tan general como el DO-WHILE, que per¬ 
mite expresar prácticamente cualquier tipo de iteración. En el 
DO-WHILE debemos expresar una condición D; si D no se cumple 
salimos del ciclo; en caso contrario continuamos en él En resu¬ 
men: el ciclo se repite (DO) "mientras" (WHILE) se verifica la con¬ 
dición. 

En cualquier planteamiento "GOTO-less" el programa entero 
está formado por bloques consecutivos que presentan un solo 
punto de entrada y un solo punto de salida, lo cual permite jun¬ 
tarlos fácilmente, como si se tratara de los vagones de un tren. 
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Las mayores ventajas de la subdivisión en bloques se obtie¬ 
nen cuando es posible su reutilización en otros programas: se con¬ 
vierten en las llamadas funciones o procedimientos de librería, 
que permiten un gran ahorro de tiempo. 

La tendencia es, pues, crear un programa principal ("main pro- 
gram") dentro del cual los distintos procedimientos (como se les 
llama en Pascal, o subrutinas como se les llama en BASIC) son "lla¬ 
mados” sucesivamente. Al estar los procedimientos escritos apar¬ 
te, cuando depuramos el programa es posible que sólo tengamos 
que modificar algún procedimiento defectuoso sin tener que to¬ 
car los demás ni el principal, o bien, más raramente, se puede re¬ 
visar el flujo del principal sin tocar los procedimientos, especial¬ 
mente si éstos se refieren a la elaboración de subrutinas (Fig. 2). 
Este es uno de los fundamentos de la llamada ingeniería del soft¬ 
ware (software engineering), que se ocupa de la construcción co¬ 
rrecta y eficiente de los programas, además de buscar su mante¬ 
nimiento de la forma más eficaz posible. Si lo pensamos deteni¬ 
damente, este principio también lo llevan a la práctica los progra¬ 
madores de FORTRAN y BASIC gracias a una cautelosa dosifica¬ 
ción de subrutinas. ¿Entonces...? Lo que el Pascal (y otros lengua¬ 
jes) ofrece de más son unas herramientas de trabajo (tools) más 
definidas y potentes. 

Hasta aquí la propaganda. Pero, ¿es realmente todo tan bonito 
como parece? 


Principio 


Principio 


Proced - A 


Proced - A 


Proced - B 


Proced - B 


Programa principal 


M Figura 2—Otro punto esencial de ¡a programación estructurada es 
la subdivisión en módulos, bajóla forma de "procedimientos", recla¬ 
mados desde el programa principal. El método ciertamente no es exclu¬ 
sivo de los lenguajes estructurados, pero éstos suministran "herramientas' 1 
más potentes. 
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Para contestar a esta peliaguda pregunta hay que hacer notar 
ante todo que, después de los furores iniciales, el extremismo es- 
tructuralista ha cedido un poco, ya sea por la práctica de los usua¬ 
rios o por las teorías de otros estudiosos menos extremistas. Entre 
estos últimos debemos citar las autorizadas opiniones de David 
Knuth (ha escrito una especie de enciclopedia de algoritmos, aún 
inacabada, llamada “The art of programming"). Knuth advirtió el 
peligro de llegar a escribir programas oscuros y enrevesados, aun 
respetando de lleno las reglas básicas de la programación estruc¬ 
turada. Responsable de estos resultados ng demasiado optimistas 
ra sido sobre todo una interpretación extremista del Teorema de 
acopini-Bohm. Efectivamente, si además de suprimir el GOTO nos 
imitamos dogmáticamente a las tres estructuras de la figura 1, 
pueden surgir fácilmente inconvenientes como los evidenciados 
en la figura 3, que, en la práctica, obligan a introducir códigos du¬ 
plicados y/o desviadores (switchs en inglés). En ambos ejemplos 
hemos entendido la equivalencia como que entre los puntos "x” 
e “y" las situaciones son idénticas en el esquema original y en el 
estructurado correspondiente. 

En el caso a), para obtener un diagrama de flujo equivalente, 
compuesto por las tres únicas estructuras básicas, se manifiesta 
en seguida la necesidad de duplicar el bloque A; de tal modo nos 
vemos reconducidos a la secuencia de A seguida de una estruc¬ 
tura DO-WHILE, con los bloques B y Á. 

El segundo ejemplo, más complicado, consiste en un bucle 
con posible salida anticipada al verificarse dos condiciones 
("p" y “q"). La reducción a módulos iterativos y de selección 
(IF-THEN-ELSE) se resuelve esta vez recurriendo al desviador 
(o “conmutador") SW; éste es una variable booleana, que sólo pue¬ 
de valer, por tanto, "true" o "false" (otras nomenclaturas equivalen¬ 
tes son: "1", "0"; "ON", "OF"; "activado", "desconectado"; "encendido", 
"apagado"). El desviador no se utiliza para ningún cálculo; sirve 
únicamente para desviar el flujo del programa cuando ocurren de¬ 
terminadas condiciones. En los diagramas de flujo la situación 
on/off de los desviadores generalmente está encerrada dentro de 
exágonos irregulares. Como se ve en la figura 3, SW está inicial¬ 
mente desconectado, para activarse después al producirse una 
de las condiciones ("p", “q”). De esta manera, al inicio del nuevo 
ciclo, en el punto “z", SW conserva rastros de lo ocurrido en "p" o 
en "q", interrumpiéndose la iteracción (punto "y"), en caso de que 
alguna se hubiera cumplido. Para comprender la función de un 
desviador se puede imaginar un tren que, al llegar a un cambio 
de agujas, puede girar a la derecha o izquierda según un suceso 
precedente (por ejemplo, que hubiera pasado otro tren). . 

Volviendo a la figura 3 hay que reconocer que se ha conse¬ 
guido descomponer todo en secuencias encerradas en una única 
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[¡Figura 3— El uso exclusivo de ¡as tres estructuras mencionadas en 
el teorema de Jacopini-Bóhm puede comportar redundancias: en -a) 
ha sido necesario duplicar un bloque, en b) hubo que recurrir a desvia¬ 
dores (switchs). 
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estructura DO-WHILE (empieza con el rombo SW arriba), pero a 
un precio que supone casi contradecir uno de los presupuestos 
mismos del estructuralismo: la claridad (y podríamos proponer 
ejemplos en los que la situación sería trágica), La culpa de estas 
situaciones no es, evidentemente, de Jacopini, ni mucho menos 
del agradable Knuth; ellos se han limitado a demostrar y compro¬ 
bar los efectos de un simple y honrado Teorema. 

, . Ahora bien, ¿es cierto que nos debemos limitar a estas tres 
únicas estructuras? Ciertamente, no. La programación estructura¬ 
da nos permite disponer de estructuras_.de control del flujo que, 
al menos sobre el papel, forman un repertorio para casi todas las 
situaciones. La figura 4 nos muestra las más típicas y difundidas. 
La sintaxis utilizada es genérica y no tiene una correspondencia 
exacta con ningún lenguaje en concreto. 

En el DO WH1LE (haz mientras...) se abandona el bucle cuan- 

nn mmwl C1Ót l S ® deja de cum P lir ( es ^a), en tanto en el 
UU-UW IL (haz hasta que...) ocurre al revés, saliendo de la itera¬ 
ción al cumplirse la condición. 

Las construcciones REPEAT WH1LE y REPEAT UNTIL funcio¬ 
nan como las dos anteriores, pero la verificación de la condición 
se hace al final del bucle, lo cual implica que, como mínimo éste 
será recorrido una vez. 

El paso de una construcción WHILE a una UNTIL, o viceversa 
es inmediato, pues basta invertir la condición (A<B en lugar de 
A>B, por ejemplo) o usar el NOT. El Pascal normalmente se limita 
a las estructuras DO-WHILE y REPEAT UNTIL 

La construcción 5) se refiere a las salidas intermedias, en tan- 
es f clásica D0 deí FORTRAN y la conocidísima FOR del 
BASIC, por lo que no merece más comentarios; sólo observar que 
el equivalente en el Pascal estándar la variación del índice sólo 
puede ser en una unidad y no se permite modificar su valor en 
el bucle. 

Finalmente, dos palabras sobre la penúltima estructura, ausen¬ 
te en la versión estándar del Pascal, pero introducida en alqunas 
versiones comerciales y aceptada también por el mismo Wirth 
en su nuevo lenguaje (Modula 2). La cláusula EXIT1F (en el len¬ 
guaje C se llama “break’ 1 , denotando una ruptura anticipada del 
ciclo al cumplirse alguna condición intermedia) corresponde a 
una situación que, en BASIC, sería expresada como sigue: 

3150 IF (CONDICION) THEN RETURN 


3200 RETURN:REM Final subrutina 

Una futura como ésta (tolerada por los puristas a pesar 
de que el EXITIF equivale a un GOTO gracias a que salta al final 
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1) DO WHILE<condición> 


REPEAT 

2) DO UNTIL <condición> 

REPEAT 

3) DO 

REPEAT WHILE <condiclón> 

4) DO 

REPEAT UNTIL <condición> 

5) DO 

EXITIF <condiclón> 

REPEAT 

6) DO VARYING ... FROM ... TO ... BY 

REPEAT 



Figura 4.—Con más variedad de estructuras podremos hacer frente 
a ¡os problemas surgidos con ia limitación a las tres esenciales. En 
tas primeras parejas la diferencia está en la condición de salida (V o F). 
El Pascal sólo adopta las construcciones DO-WHILE y REPEAT UNTIL. Es 
útil la nosibilidad de salida anticipada (EXITIF, llamada a veces "break"). 
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del procedimiento, salvando así el principio de que sólo exista un 
único punto de salida) resuelve problemas como los del ejem¬ 
plo b) de la figura 3, permitiendo la interrupción de un ciclo al 
hacerse verdadero algún test interno a él; de esta manera se 
subdivide, de hecho, en distintas ramas. 

- .</ >ara com P^ etar cuadro, debemos mencionar la estructura 
CASE. Actúa aproximadamente como la ON <condición> GOSUB 
xx, y y, zz del BASIC. CASE realiza un test con soluciones múlti¬ 
ples (superior a dos), para cada una de las cuales tiene definidas 
las acciones que hay que cumplir y/o kjs procedimientos a los 
que debe recurrir. En esencia es una ampliación de la IF-THEN- 
ELSE, con distintos anidamientos a niveles jerárquicos inferiores. 


IF (condic. - 1) THEN 
BEGIN 

instrucción - 1 

DO VARYING I FROM 1 TO 60 
IF (condic. - 2) THEN instrucción - 2 

ELSE instrucción - 3 

ENDIF 

REPEAT 

END 

ENDIF 


Nlvol 0 


Nlvol 1 


Nlv.il 2 


Nlvol 3 


Nlvol r! 



1 Figura S.—El andamiento de estructuras con distintos niveles jerár- 
<tmcos es típica de los lenguajes estructurados. Se suele representar 
medí,mte "indentación" usando márgenes diversos. 
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MAS SOBRE EL TOP-DOWN: ESTRUCTURAS 

DE DATOS 


Ser abstractos para resultar concretos 



menudo nos olvidamos que la elaboración de 
datos no se limita sólo al cálculo numérico, aun¬ 
que los ordenadores hayan nacido con este fin 
(tanto es así que mucha gente sigue llamándo¬ 
los calculadores). El cálculo matemático se ini¬ 
cia seriamente con el filósofo y matemático Blai- 
se Pascal (no es una coincidencia: Wirth llamó 
Pascal a su lenguaje en honor de Blaise); inven- 
——, tó la "Pascaline", una máquina de sum^ pá¬ 

nica a base de ruedas, precisamente porque se apiadó del traba¬ 
jo contable tan inhumano que su padre, recaudador real realza¬ 
ba. La historia de los computadores se refiere muchas Veces al 
“number crunching", es decir, a la necesidad voraz e incesante de 
números: en la preparación de tablas de ‘jro giencia ^lísticaX en 
los complicados cálculos de proyectos científicos como la caza 
de las partículas subatómicas del premio Nobel Rubbia , técnicos 
(CAD/CAM) o, más banalmente, en los cálculos contables. 

Quizá fueron los trabajos de gestión los que abrieron camino 
a la idea de que el ordenador podía hacer algo más que una serie 
de operaciones aritméticas: podía manipular hábilmente muchos 
otros Tipos de Datos. Cuando se tiene que trabajar con listas 
(clientes proveedores, etc.) hay que archivar, leer y manejar can- 
tidales enormes de da.os, ímméricos y alfanuméncos^AiJil se mi- 
ció la elaboración no-numérica, que posteriormente ha dado orí 
gen a la misma denominación de Ciencia de la Información. Como 
ocurre siempre, tanto en la historia del hombre como en la de la 
ciencia, primero se encuentran soluciones parciales, y luego, con 
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los primeros problemas, surgen momentos de crisis que dan lu¬ 
gar a úna más profunda reflexión teórica. 

Este proceso se complica por la caótica evolución de los so- 
podes informáticos, favorecida por la ausencia de normas Enu¬ 
meramos a continuación algunos soportes que se han ido suce¬ 
diendo en el campo de la informática: tarjetas perforadas, cintas 
perforadas, cintas magnéticas, tarjetas magnéticas, tambores mag- 
néticos, discos magnéticos rígidos, flexibles (disquetes o floppy 
disk). Nos paramos aquí, aunque teniendo en cuenta que, por una 
parte, hay otros a punto de aparecer (djscos ópticos) y que, por 
otra, cada uno de los soportes mencionados no sólo se basaban 
en tecnologías diferentes, sino que requerían distintos "formatea¬ 
dos y codificaciones, y peor aún, una organización y estructura 
de los datos grabados incompatible casi siempre. Por poner un 
ejemplo clásico, en la tarjeta Holíerit, adoptada por el IBM, sus 80 
caracteres, tantos como columnas agujereadas constituían el re- 
gistro (o récord): una verdadera camisa de fuerza. Además, la tar¬ 
jeta de 80 caracteres era "el registro" por antonomasia. Otro límite 
venía dado en este como en otros sistemas de almacenamiento 
externos (en la jerga informática se habla de "memorias de masa- 
para evidenciar su gran capacidad en relación a la de la memoria 
interna) por el hecho de que el acceso era secuencial, es decir 
que para alcanzar un dato (o grabación) intermedio hay que leer 
antes por fuerza todos los anteriores aunque no nos interesen. 
Alobunadamente, hoy existen memorias de acceso directo o alea- 
tono (random en inglés) en las cuales el dato buscado se puede 
obtener de forma directa, como ocurre en las memorias RAM (si¬ 
glas que quieren decir Random Access Memory, memoria de ac¬ 
ceso aleatorio). 

I odos estos problemas iniciales hicieron que se sintiera como 
uri.i necesidad definir estándares también en los datos, es decir, 
i|.n lipes válidos universalmente. La cosa surgió bastante espon- 
,1,'niñamente con el desarrollo de los lenguajes de programación 
pi nblom-onented", dirigidos a los problemas de las personas y 
, lln exigencias y particularidades de la máquina. Mientras en 
i '< ’nquajes "machine-oriented" se habla de bits, bytes campos 
1 V Ul, l n !: i;í ' ®tc,en los "problem-oriented" se refieren a los tipos 
, 11 P ara distinguirlos de los físicos; así existen, por ejemplo 
H i<!< jiiilro lógico CLIENTE por una parte, y por otra, la posición 
. m l,i cual se graban los datos. La grabación física puede di- 
11111 chl1 11 >gistro lógico en su organización: por ejemplo, en una 
1 1 "I■ 1 niriqnéljca puede ocurrir que la grabación física contenga 
"" 1111,1 llll!: '" a Züna ] °s datos de varios clientes, por motivos de 
" ll " m1,1 (| " espacio; también se pueden encontrar codificacio- 
!" 1 1 1 "' "‘Uponen la disgregación de los datos en diferentes loca- 
1,1 ". . ,ísir;as (F«g- !)■ El usuario, ciertamente, no quiere saber 
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<- Sector o bloque -* 



M Figura l—El registro lógico puede no coincidir con el de la graba¬ 
ción física. Por ejemplo , en una cinta o disco magnético pueden es¬ 
tar contenidos en un mismo bloque o sector varios registros lógicos pues¬ 
tos uno tras otro. 


nada de estos asuntos, ni mucho menos enloquecer pasando de 
un sistema de grabación física a otro. Muy pronto se produjo la 
evolución de los datos; en un lenguaje de alto nivel no es opera¬ 
tivo estar obligado a trabajar sólo con bits y bytes. Asi, el vetusto 
FORTRAN, desde sus primeras versiones ofrecía variables ente¬ 
ras, reales, en simple o doble precisión, alfabéticas, cadenas, y 
otras más complicadas, como tablas, vectores y matrices. 

También en este caso se reafirma el principio de indepen¬ 
dencia de la máquina, que conduce a la definición lógica o, como 
hoy se dice, abstracta de los datos. Así. pues, habremos de ser abs¬ 
tractos en los datos para que los resultados puedan ser concretos. 


Tipos de datos 

La programación estructurada —lo hemos dicho más tle una 
vez, pero insistiremos todavía aún a costa de ganar el Oscar del 
aburrimiento— significa, entre otras cosas, estructuración de los 
datos. Como se comentó en el apartado precedente, se trata, en 
primer lugar, de una operación de abstracción, sentido de que 
prescinde al máximo de las modalidades de implementación de 
un cierto conjunto de datos. En otros términos, con los Datos Abs¬ 
tractos, el énfasis se pone en su significación, en su aspecto lógi¬ 
co. Esto se hace así para asegurar la máxima transportabilidad del 
software de un sistema al otro. ¿Qué se entiende por "transporta¬ 
bilidad"? Lo explicamos en dos palabras: un software se dice trans¬ 
portable cuando, habiendo sido escrito para un determinado or¬ 
denador. funciona a la perfección también en otros. 

Este ideal, nacido ya con los primeros lenguajes de alto nivel,- 
culmina hoy con el lenguaje Ada (potentísimo y superestructura- 
do, aunque no adecuado para ordenadores personales), que, 






desarrollado para el potente Departamento de Defensa USA, 
busca ser un verdadero esperanto informático y permitir que el 
D. D. USA pueda hacer funcionar un determinado programa en 
una máquina de cualquiera de las innumerables y variadas 
marcas de las que está dotado el Ministerio de Defensa, con 
todas sus divisiones y departamentos. 

Antes de continuar y de... concretar el discurso sobre la abs¬ 
tracción (¡finalmente!) hay que apuntar, por lo menos, el hecho de 
que esta tipología abstracta ideal está todavía lejos de ser perfec¬ 
ta. En nuestro tratamiento del Pascal, que tiene fines exclusiva¬ 
mente, didácticos y formativos nos ocuparemos casi exclusiva¬ 
mente de los tipos de datos que residen, también físicamente, en 
la memoria interna. 

El concepto de tipo abstracto de datos significa dos cosas: 

• un conjunto de valores o campo de existencia de unas ca¬ 
racterísticas dadas, 

• un conjunto de operaciones que se puedan hacer sobre 
esos valores. 

Un ejemplo banal sería el tipo "entero" (INTEGER en Pascal) 
que obviamente se refiere a los números enteros algebraicos, y 
cuyas operaciones son aritméticas; pero podemos añadir otros in¬ 
ventados por nosotros. Veamos un par de ellos, prescindiendo en 
ambos casos de cualquier lenguaje de programación. 

Primer ejemplo: CASAS COLOREADAS. 

Definición: el conjunto de casas que hay que pintar 

Operaciones: pintar de blanco, pintar de rojo, pintar de azul... 
(muy a menudo se trata de enumeraciones exhaustivas: ¡se evita¬ 
rán, espero, casas pintadas de horrendos colores, como el morado 
o el negro!). 

Segundo ejemplo: CARTAS DEL TUTE. 

Definición: conjunto de cartas de los cuatro palos (copas, es¬ 
padas, oros y bastos) del as al rey. 

Operaciones: barajar, distribuir a los jugadores... 

Ya con el segundo ejemplo se comprende en seguida una 
particularidad: un tipo, por ejemplo CARTAS DEL TUTE, puede 
subdividirse en sub-tipqs (los palos). Para volver a asuntos que tie¬ 
nen que ver más directamente con la informática podemos recor¬ 
dar que un subtipo elemental del tipo "integer" es el CARDINAL, 
constituido sólo por los enteros positivos (distinción que alguien 
podría encontrar un poco nimia, pero que a veces es útil). Imagi¬ 
nemos ahora que definimos un nuevo tipo (existe realmente y es 
muy importante) llamándolo PILA (en el sentido de montón, stack 
en inglés). Una pila estará formada por datos apilados unos sobre 
otros, según el orden de llegada y que se pueden extraer uno a 


uno de la parte superior (top del stack), evidentemente, en orden 
inverso respecto al de acumulación (si intentáramos sacar otro si¬ 
tuado debajo, los que estuvieran por encima se “caerían"). Por eso 
i 'I stack se llama también memoria LIFO (Last In First Out, último 
< -n entrar, primero en salir), traducción libre del evangélico "los úl¬ 
timos serán los primeros" (Fig. 2). * 

Las operaciones del tipo PILA que definiremos son, principal¬ 
mente: 

• PUSH (empuja). Consiste en acumular un dato nuevo en la 
parte superior. 

• POP (tira). Operación inversa. Recupera un dato de la cima, 
con la consiguiente reducción de los elementos de la pila. 

• TOP. Copia el dato de la cima, pero sin modificar el conte¬ 
nido de la pila. 

Como es obvio, un buen lenguaje de programación debe pro¬ 
veer al usuario de una cantidad adecuada de tipos predefinidos. 

La potencia de un lenguaje se mide también por la cantidad 
(y calidad) de los tipos de datos que puede manejar. El pobre 
BASIC lo es de verdad, bajo este punto de vista, dado que 
generalmente ofrece sólo los tipos entero, real (en simple y a 
veces en doble precisión), cadena y matriz. 

El aspecto de mayor relevancia de la programación estruc¬ 
turada, presente en todos los lenguajes que se inspiran en ella, re¬ 
side en que tiene la posibilidad de crear nuevos tipos, definidos 
por el usuario en base a sus necesidades particulares. Los nuevos 
tipos se construyen a partir de los predefinidos, ofrecidos por el 
lenguaje. Una vez más la idea es la de realizar una construcción 
con las piezas del Lego, o si se prefiere, las de un puzzle. t 
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Figura 2.—Esquema general de una pila (stack). La operación PUSH 
carga un dato nuevo en la cima de la pila, mientras que la POP ex¬ 
trae el dato situado "arriba"modificando la pila. Se puede dar también una 
operación TOP que coge este dato y lo copia sin modificar la pila. 







De este modo se pueden proyectar los tipos más adecuados 
a cada problema determinando al mismo tiempo una neta y clara 
separación entre tipos heterogéneos. Dicho familiarmente: no se 
deben confundir manzanas con peras, tal y como nos enseñaban 
en la escuela. Las mayores aportaciones a la creación de estos 
conceptos vinieron del habitual trío de gurús (Hoare, Dahl y 
Dijkstra). El gran mérito de Niklaus Wirth ha sido implementarlos 
en sus lenguajes (Pascal y Modula-2). 

Pongamos ahora un poco de orden, subdividiendo los tipos 
de datos en dos categorías: 

• simples, 

• compuestos. 

Tipos simples 

Podrían llamarse también atómicos, no por referencia a la 
energía atómica, sino aludiendo al hecho de que se trata de valo¬ 
res elementales, sin posibles subdivisiones ulteriores. Los com¬ 
puestos, en cambio, son tipos construidos a partir de los simples, 
por adición. 

Los simples no se limitan a los definidos a priori como parte 
del lenguaje (típicamente, los conjuntos de números enteros, rea¬ 
les, caracteres alfa numéricos y valores booleanos). El Pascal y 
otros lenguajes estructurados permiten definir nuevos tipos sim¬ 
ples, generalmente mediante dos técnicas: enumeración e inter¬ 
valo (range), 

El ejemplo que sigue aclara estos conceptos: está escrito si¬ 
guiendo una sintaxis que se asemeja mucho (y a menudo coinci¬ 
de) a la del Pascal, sin atenerse con exactitud a las reglas. En suma, 
una anticipación que, ya puestos, nos familiariza con el Pascal. Las 
palabras reservadas o sea, típicas del lenguaje, están escritas to¬ 
das con mayúsculas. 

TYPE diase*=(lunes,«artes,niercoles,jueves, 
viernes,Babada,doningo); 
dialab=lunes..viernes 

VflR x:diasen)!v:dialab; 

Se trata de parte de la sección de un programa en la qué se 
definen los tipos y las variables. Los que conozcan sólo el BASIC 
notarán en seguida que el Pascal y sus afines son más sofistica¬ 
dos. Por desgracia, es verdad. Como compensación, son extrema¬ 
damente más claros de leer (¿claridad y síntesis juntas? ¡imposi¬ 


ble tenerlas en un mismo lenguaje!). Las líneas que acabamos de 
ver nos dicen que el programador ha querido definir un TYPE 
(tipo) diasem, enumerando las siete expresiones alfabéticas entre 
paréntesis. Después de haber utilizado la técnica de la enumera¬ 
ción ha recurrido a la del rango; creando el tipo dialab, constitui¬ 
do por los días que van desde el lunes hasta el viernes (los cua¬ 
tro puntitos en la sintaxis del lenguaje suponen todo lo interme¬ 
dio entre los dos valores señalados). Posteriormente se definen 
las variables "x" e "y” con la palabra reservada VAR como perte¬ 
necientes, respectivamente, a los nuevos tipos de diasem y dia¬ 
lab; la asociación se establece, como pueden ver, mediante los 
dos puntos (:). 

Estamos seguros de que, llegados a este punto, alguien po¬ 
dría encontrar banal todo lo anterior. ¡Y efectivamente, lo es!, pero 
son precisamente las ideas banales (en apariencia) las interesan¬ 
tes, desde el huevo de Colón a la manzana de Newton. 

El mérito de toda esta gente de apellido extraño (Wirth, 
Dijkstra... ¿cómo se pronuncian?; no lo sabemos) es doble; 

• haber trazado un camino, esclareciendo públicamente 
cosas que quizá algunos programadores hacían ya por ins¬ 
tinto; 

• poner a nuestra disposición instrumentos prácticos para 
obtener una implementación cómoda de los tipos más 
complejos, que nos permitan hacer frente a ¡as más varia¬ 
das necesidades. 

Es inútil decir que en la mayoría de los otros lenguajes tradi¬ 
cionales de alto nivel no podríamos hacer nada por el estilo, y nos 
las tendríamos que apañar con tipos predefinidos (números o, 
como mucho, tablas). Con los nuevos medios se gana sobre todo 
:-n claridad, además, el lenguaje compilador está ahora en fcondi- 
ciones de señalar, en el momento de la traducción del programa, 
errores de forma que podrían corresponder a errores de esencia. 
Pongamos el caso de que, por algún extraño motivo, se asigne a 
una variable '‘y", definida del tipo dialab, un valor como sábado o 
domingo: el compilador, antes de que el programa sea ejecutado, 
se da cuenta en seguida de que sábado y domingo no pueden atri¬ 
buirse a una variable que no incluye las fiestas, y nos lo indicada. 

Otra pequeña observación en relación con el fragmento de 
lenguaje estructurado que acabamos de ver: cuando se define un 
nuevo tipo por enumeración, como en el caso de diasem, se está 
dando a la vez una determinada disposición que es la misma de 
i ú enumeración. Así, en nuestro ejemplo, el lunes está antes que 
el martes, que está antes que el miércoles, etc. Esto es lo que nos 
permite definir después otros tipos por rango, como hemos visto 
para dialab. 
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Tipos compuestos o estructurados 


Los tipos compuestos (también llamados estructurados) 
pueden construir generalmente —es el momento de decirlo— por 

medio de las siguientes operaciones: 

• producto cartesiano, 

• unión discriminada, 

• array o matriz, v. 

• conjunto potencia, 

• secuencia. 

Hay que subrayar que se ha apuntado una situación ideal, 
pues ningún lenguaje es hoy en día tan potente como para imple- 
mentar todas estas posibilidades, ofreciéndoselas al programador 
para que se fabrique sus propios tipos. Pasemos lista rápidamen¬ 
te, dando simples ejemplos ilustrativos. 

El producto cartesiano parte de dos conjuntos genéricos, 
A y B, para obtener el conjunto-producto C = A * B cogiendo to¬ 
das las posibles parejas de elementos, ordenados tomando el pri¬ 
mero de A y el segundo de B. He aquí un ejemplo clarificador: 

TYPE palo=(copas,espadas,oros,bastos)¡ 
valor=1..10 
carta=(p:palo;v:valor) 

Sin adentrarnos en cuestiones sintácticas (recordemos sólo 
que los dos puntos, como ya hemos visto, preceden a la indica¬ 
ción del tipo) debería estar claro que el tipo estructurado carta 
está formado por parejas de elementos ordenados, el primero del 
tipo palo, el segundo de tipo valor. Así, una pareja como (espa¬ 
das; 1) identifica el as de espadas. Definiendo por enumeración el 
tipo simple valor, hubiéramos podido tener, obviamente, elemen¬ 
tos estructurados como (espadas; sota) (bastos; rey), etc. 

Otros ejemplos parecidos podrían ser: 

TYPE cliente=(no:nonbre;dir:direccion;cp:codigopostal; 
ciuiríudad); 

artic=(cod:codigo;dBs:descripcion;dp:deposito); 

Esta estructura corresponde en Pascal, en esencia, al tipo 
RECORD que viene dado como estándar. He aquí un ejemplo 
sencillo: 
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TYPE íecha=RECQRD 
d:dia; 
asees; 

asanno !* el pascal no acepta la S *) 

END; 

Generalmente RECORD y END son palabras reservadas que 
también hacen de limitadores, es decir, están en el lugar de los 
paréntesis de los ejemplos precedentes. Es superfluo decir que 
se sobreentiende qué nombre, dirección, día, etc., habían sido de¬ 
finidos con anterioridad. 

En cuanto a la unión discriminada, parte de dos o más con¬ 
juntos para constituir un tercero, en el que están presentes tanto 
ios elementos del primero como los del segundo. Sirve para mez¬ 
clar los tipos, fundiéndolos en uno de carácter más general en el 
que, a pesar de todo, cada subtipo conserva su propia estructura, 
o sea, su identidad. Esta se discrimina o distingue por medio de 
un oportuno campo común, cuyo contenido es netamente diferen¬ 
te en los dos casos. 

Lo explicaremos con un ejemplo, también ilustrado en la 
figura 3: 

TYPE autenac=<censtr:fabricante;oatriciila:nuaatr¡ 
propiet:persona;prinereg:fecha); 
autoext=(constr;fabricante;natricula:nüfflatr; 
nacorigsnacion) ¡ 

auto=<nacional¡autonac;extranjero:autoe>:t); 

t 



Constr. Matricula Propiat. Primeree 

auto 






Mercedes 

XY3254 

Alemania Federal 

1 auto ext(ranjero) 


Constr. Matricula Nac. orig. 


gSS3 Figura 3— Con la operación de unión (discriminada) es posible uni- 
íms [¡car bajo una misma categoría los tipos "con variantes", sobre la 
base del contenido de un campo discriminante común. 
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Aquí, los tipos autonac y autoex (referentes a automóviles na¬ 
cionales y extranjeros), ya estructurados por su cuenta, tienen en 
común el campo constr (nombre del constructor), mientras que 
en el resto tienen diferencias apreciables (el campo nacorig —na¬ 
cionalidad de origen— que no tiene sentido con coches de tipo 
autonac). El nuevo tipo auto definido por unión (también se dice 
función OR) permite distinguir del montón aparentemente unifor¬ 
me los coches nacionales de los extranjeros, en base al campo co¬ 
mún constr. Aquí dejamos al lector que imagine cómo se puede 
pensar en listas separadas de constructores locales o, más drásti¬ 
camente, en una subdivisión del campo constr en dos subcam¬ 
pos, el primero conteniendo una N o una E, según los casos. 

Esta estructura de datos está presente en el Pascal con el nom¬ 
bre de RECORD con variantes. 

Veamos ahora los tipos compuestos formados como arrays, 
ya familiares a los conocedores del FORTRAN o del BASIC. El t oo 
array (que quiere decir "matriz") es un conjunto matr obtenido me¬ 
diante un conjunto ind, de los Índices, y otro val de los valores. 
Cada uno de los Índices se podrá asociar a uno de los valores. A 
diferencia de los vectores o tablas de los lenguajes tradicionales, 
el array, según la concepción de Hoare, permite también la utili¬ 
zación de índices no numéricos. 

En Pascal la forma general es la siguiente: 

TYPE matr=ARRAY[ind] OF VAL; 
por ejemplo 

TYPE diames=ftRRñY[ine53 OF 28..31; 

el índice mes es un tipo no numérico definido anteriormente por 
enumeración de los meses (de enero a diciembre), mientras que 
el campo de los valores está definido por intervalos (da sólo los 
valores posibles, pero.no los asocia con el índice; aquí, por ejem¬ 
plo, no dice que el primer elemento del mes-tenga 28 días). 

Una posible aplicación de este tipo estructurado recién defi¬ 
nido podría ser: 

VftR diassdiaites 

y en el curso del programa se podría utilizar la asignación: 

diasCfehrero]:=28; 

Para información de los que no lo saben, anticipamos que, en Pas¬ 
cal, el signo = sirve para definir tipos o señalar la similitud entre 


términos comparados, mientras que para la asignación se hace 
preceder el = por dos puntos (:=), así se elimina el equívoco de 
asignaciones como N = N + 1, (escribiendo N: = N + 1 es mas evi¬ 
dente que N se "convierte" en N + 1...) 

Otro ejemplo, altamente elocuente (eso esperamos) es. 

TYPE paloDoker=(coraione5,diamantes,tréboles,picas); 
valpoker=1..3¡ 

cartapok=(palo:palopoker;valor:vaipaker); 
barajpak=ftRRAVC1..521 OF cartapak; 

Veamos ahora el conjunto potencia. Se parte de un conjunto 
de datos y se forma el de todos los subsistemas que lo 
nen incluido el conjunto vacio (a veces llamado mi por los 

informáticos) y el total. Imaginemos un rebaño de cuatro ovejas. 
a b c d. El rebaño-potencia estaría formado por: el rebaño vacio 
(ninguna oveja), los rebaños de una oveja (a..xl), losde dos¡ove¬ 
jas (ab ac, ad, be..., cd), los de tres ovejas (abe, abd.., bed) y el 
abed. No nos extrañemos de que exista un "rebaño vacio : piense 
en un pastor al que le han robado todas las ovejas. 

En Pascal, la palabra reservada que sirve para definir un con¬ 
junto potencia es SET He aquí un sencillo ejemplo. 

TYPE colorbase=(rojo.amarillo.azul); 
color SET OF colorbase; 

después de lo cual es posible, una vez definida una cierta 
VftR col¡color 

hacer una asignación como col: = (amarillo, azul). Como informa¬ 
ción diremos que esta estructura tan cómoda en algunos casos es 
criticada sobre todo por la dificultad de implementaciones eficien¬ 
tes. En efecto, para identificar a cada elemento del conjunto po¬ 
tencia son necesarios al menos tantos bits como elementos tenga 
el conjunto de que se parte. La identificación más sencilla que se 
pueda imaginar consiste en poner un bit a 1 ó a O, según que el 
elemento esté o no presente (una implementación que utilizase 
una qrabación independiente del resultado exigiría espacios pro¬ 
hibitivos). Por ejemplo, en el caso de la tricromía arriba expuesto 
son necesarios 5 bits y la asignación col: = (amarillo, azul), corres¬ 
pondería a 011. Imagínese lo que ocurriría con conjuntos base in¬ 
cluso de pocos centenares de elementos., 

Aún más pesado desde el punto de vista de la realización es. 
el modo secuencia, que se fabrica con un conjunto X de n ele¬ 
mentos tomando todas las posibles secuencias (ordendas) de ele- 


meníos, desde la secuencia vacía a aquellas formadas por 1 , 2 ..., 
"n" elementos. 

TYPE cadena=SEQUENCE carácter 

identiticador=(primcari 1etra:resto:SEQUENCE(1:letra,d:dígito)) 

El primer caso define una cadena como un conjunto cualquie¬ 
ra de caracteres ordenados. En el segundo se trata de un identi- 
ficador, entendido como la sucesión de letras o cifras, en las que 
el primer carácter es siempre una letra^i alguien no ve muy cla¬ 
ro todo esto, debe de tener presente que no estamos profundi¬ 
zando en el campo estructurado, con lo cual éstos no son más que 
sencillos ejemplos (incluso algunas cosas no las profundizaremos 
ni siquiera posteriormente). En Pascal, el tipo que más se parece 
a la secuencia es el tipo 'Tile", que constituye una implementación 
reducida, dado que se refiere solamente a la memoria externa. 


TYPE dirección = 




RECORD 
Calle: STRING; 
Núm: INTEGER: 
Cp: INTEGER; 
Ciud: STRING; 
END; 


TYPE nombre prop = RECORD 

nombre: STRING; 
apellidos: STRING; 
END; 

TYPE linea = RECORD 

nomb: nombre prop: 
dlr: dirección; 
número: INTEGER; 
END; 

TYPE página « ARRAY (1. . núm. 

lineas) OF línea; 

TYPE guíatelf = FILE OF página; 


TYPE página 


TYPE guíatelf = 
VAR gu!a;guiatelf; 


--1 --1-1-PAGINAS 

M Figura 4.—Con los tipos estructurados es fácil construir con refina¬ 
mientos sucesivos ¡as más complejas construcciones de datos com¬ 
puestos. En la figura tenemos el ejemplo de una guía de teléfonos, destri- 
ta como un archivo formado por array-página, a su vez compuesto por re¬ 
cord-linea, conteniendo cada uno una dirección, subdividida en... Para fa¬ 
cilitar su comprensión, la descripción formal de la figura es en bottom-up 
De todas formas es evidente el uso de! mecanismo nidificado, típico de la 
programación estructurada. 
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Después de todo lo hablado sobre los tipos "abstractos puede pa 
recer una traición, pero el hecho es que también en los terrenos 
más avanzados se debe distinguir entre sueño y realidad, ideales 
y límites objetivos. , 

En la figura 4 hallamos un ejemplo resumido que debería es¬ 
clarecer el procedimiento top-down con sus fases de refinamien¬ 
tos sucesivos, paso a paso ("step refinements") en la definición de 
datos estructurados. 


Conclusiones provisionales 

En la figura 5, para comodidad del lector se representa el cua¬ 
dro sinóptico de las estructuras presentes en Pascal, anticipando 
lo que explicaremos mejor más adelante (nos referiremos enton¬ 
ces también a los "pointers" o punteros, que nada tienen que ver 
con los perros de caza). 

Para concretar la panorámica de las prestaciones que se pue¬ 
den conseguir con la ayuda de Hoare y compañía, traeremos aquí 
un caso de aprovechamiento de la recursividad ("recursivity en 
inglés). Todo proceso recursivo tiene un carácter extraño: se ña¬ 
ma a sí mismo Tendremos ocasión de volver a oír hablar de re- 


Tlpos de datos 



Enteros Caracteres 


Reales Booleanos 



ofrecidos por el lenguaje 
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cursividad, a propósito de los programas. Este concepto moderno 
se aplica aquí a la definición de datos estructurados y consiste en 
el hecho de que la expresión se llama a sí misma desde el inte¬ 
rior de su definición: 

TVPE expresi on=SECUENCE termino; 

terrainQ=(addop:operador;-f: SEI3UENCE factor); 
factor=(mutrhap: operador; p: pri nari o); 
primar i d= (CONST: (val: real (id; identificado^, 

entreparent:<e:expresion>)¡ 
operadDr=(+, 

(Para ser sinceros, en el Pascal corriente esta estructura "top- 
down" sería rechazada por el compilador..,) 

No hay que desesperar si no consigue hacer otra cosa que 
intuir para qué sirve la compleja construcción precedente (pero 
debería quedar claro que se trata de una expresión algebraica...) 
De todas formas hay que explicar que, generalmente, en la nota¬ 
ción de Hoare la coma expresa alternativa OR y el punto y coma 
AND o sucesión. Debe ser suficiente observar que "expresión" fi¬ 
gura dentro de su definición. 

Para acabar es necesario hacer notar de nuevo que el apro¬ 
vechamiento de todas las ventajas que se podrían esperar, en teo¬ 
ría, del paralelismo entre Ja estructura de los datos y los procedi¬ 
mientos de elaboración no es completa, ni mucho menos perfec¬ 
ta, en los lenguajes estructurados del mundo real. Lo ideal, en efec¬ 
to, sería que se ofrecieran posibilidades más amplias para definir, 
junto a los tipos, operaciones características sobre ellos. Quitémo¬ 
noslo de la cabeza: ni siquiera el tan celebrado Ada (nota 1) cum¬ 
ple en su totalidad esta promesa, que supondría el despliegue de 
una potencia y una flexibilidad enormes, haciendo posible, entre 
otras cosas, cambiar las modalidades operativas sin necesidad de 
modificar las instrucciones. 

De todas formas, ahora que estamos a punto de introducirnos 
en el mundo del Pascal popular, no hay que olvidar un concepto 
que intentaremos desarrollar ampliamente: Las estructuras de los 
datos y de los programas están íntimamente ligadas. 

Fijemos bien esta frase en nuestro cerebro, porque vale para 
todos los ambientes de programación, por pobres y espartanos 
que sean. 

Con ello nos adelantamos a una pregunta que se oye a me¬ 
nudo: pero si yo tengo que trabajar en BASIC' ¿para qué me sirve 
estudiar el Pascal si después, en BASIC, no poseo los instrumen¬ 
tos adecuados? 

La respuesta tiene tres apartados: 


• ¡no es nada malo acostumbrarse a trabajar en Pascal!; 

• el Pascal es altamente formativo, aporta ideas de validez 
general; 

• muchas de estas ideas se pueden transportar, con adapta¬ 
ciones más o menos complicadas, también al BASIC (me¬ 
jor si es un dialecto moderno, estructurado). 

A propósito de las estructuras de datos, en BASIC faltan cier¬ 
tamente los medios para realizar con comodidad, supongamos, un 
tipo pila (stack). Es más, el tipo stack siempre será un polizón, su¬ 
bido a bordo sin documentos, o, mejor, escondido bajo un disfraz 
falso. Nos tendremos que apañar con un vector, lo que conlleva 
grandes responsabilidades, porque el control del stack y de la le¬ 
gitimidad de sus operaciones tendremos que hacerlo todo noso¬ 
tros (el intérprete BASIC no nos ayudará en absoluto, pues no sabe 
nada de pilas ni de cualquier otra cosa que no sea tipo integer, 
real, string y vector.) La idea de un stack es válida en los casos 
en que éste sea oportuno y convendrá que pensemos en ello. 
También con el BASIC. 

Nota 1. La ya citada Ada, condesa de Lovelace, era, en vida, la hija 
del poeta inglés del siglo xix Lord Byron. Apasionada por las ma¬ 
temáticas, colaboró activamente con el que puede ser definido 
como el inventor del primer ordenador, con un programa regis¬ 
trado en memoria: Charles Babbage (1792-1871). Por eso, la bella 
Ada es considerada, aunque con mucha exageración, la primera 
programadora de la historia. De aquí el nombre dado al lenguaje. 
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LA TORTUGA GUIA NUESTROS PRIMEROS PASOS 

EN PASCAL 


.Mii. V espués de la panorámica top-down de los capí- 

pXi¿mj 0 tulos anteriores procederemos ahora justo al 
0 contrario con una orientación bottom-up (pro- 
0 gramación ascendente) 

/ m \JB ~ En el desarrollo concreto de los programas 
es una práctica bastante frecuente que los de- 
talles de un procedimiento (nos tenemos que 
mSEm acostumbrar a este término, que en Pascal de- 
signa lo que en otros lenguajes se denomina 
subprograma o subrutina) sean desarrollados en primer lugar, es¬ 
pecialmente si se trata de partes delicadas, que realizan un papel 
central en el programa y que quizá puedan ser reutilizadas más 
veces en otro lugar con o sin modificaciones. Ejemplo: un proce¬ 
so (se dice algoritmo) de ordenación C'sort") o, más banalmente, 
la búsqueda del mayor elemento en una matriz de datos. Para li¬ 
gar las piezas del puzzle hay que identificar por lo menos las prm- 

Clf>a ! No contradice todo esto el proceso top-down? En absoluto: 
una visión de conjunto es indispensable, sólo que en la fase cons¬ 
tructiva” a menudo hace más de "fondo” que de otra cosa. De jo- 
das formas se trata de estilo y gustos personales; por lo tanto, de¬ 
jémonos de discursos y entremos de lleno en la materia. Para ha¬ 
cerlo, adoptaremos la técnica de exposición del profesor Kennetn 
Bowles de la universidad californiana de San Diego. Es el padre 
de la versión Pascal UCSD (University of California at San Diego), 
En realidad, el UCSD Pascal es, más que un lenguaje, un sistema 
operativo, que integra al Pascal. Por desgracia, los fines que nos 
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proponemos y el poco espacio disponible no permiten hacer más 

a las modalid ades con las que en am¬ 
biente UCSD se editan y diseñan los programas. 

E1 acercamiento de Bowles es muy útil en plan pedaqóqico 
ya que no requiere de los alumnos ninguna noción previa par¬ 
ticular, ni siquiera de matemáticas elementales, por lo menos en 
un primer momento. En efecto, hace referencia a una tortuga (Turt- 
e), imaginario animalito que está en el centro del lenguaje Logo 
(como vimos en el volumen 6 de la BBI). Hay que añadir que las 
instrucciones inherentes a la tortuga no ferman parte del lenquaje 

faléqnfcá de^lSría^ 30 añad¡do eon fines didác!ic °s, siguiendo 

Pero veamos cómo nos podemos familiarizar inicialmente con 
¡a tortuga, y así dar también un vistazo al UCSD Pascal. Al princi¬ 
pio aparece una línea de órdenes simplifícadamente del tipo si- 

CfUISntG! 

Command: E(dit, R(un, F(iler, C(ompile, X(ecute). 

Es un simple menú interactivo, cuyas opciones se seleccio¬ 
nan tecleando sólo ¡a letra inicial de la orden: E por Edit, F por 
File etc, En nuestro caso teclearemos la X de eXecute, después 
de lo cual escribimos la palabra siguiente: 

TURTLE 

Es el ábrete-sésamo correcto. En palabras más serias quiere 
decir que llamamos al programa omónimo de la librería de pro¬ 
gramas (tiene que estar ya en el disco, si no se producirá un error) 
Después del habitual zumbido de la unidad de disco (drive) apa¬ 
rece en el centro de la pantalla la flechita que representa el ima¬ 
ginario animalito, que se podrá entonces mover a voluntad La fi¬ 
gura 1 ilustra el efecto de algunas órdenes. Es fácil de compren¬ 
der, pero de todas formas aprovechamos para recordar que la 
Turtle geometry 1 ’ es una geometría de movimientos relativos Es¬ 
tos se refieren a la posición actual de la flecha: se puede qirar en 
sentido antthorario (ángulo positivo) u horario (ángulo neqativo) 
o moverla hacia delante (valor positivo) o hacia atrás (valor ne¬ 
gativo). En el caso de la figura 1 la sucesión es: al principio la tor- 

ÜdínMnvrfJhf 1C10 ? de parti ^ : des P ués se ve el efecto de la 
orden MOVE (40) que la mueve 40 pasos elementales; TURN (90.) 

la hace girar en ángulo recto; la tortuga se mueve luego 20 pasos. 
En la quinta figura, en cambio, aparece el efecto de una secuencia 
entre las 9 ue se encuentran PENCOLOR (NONE) v 
PENCOLOR (WHITE), que sirven, respectivamente, perL anular y 
restablecer la acción de la pluma imaginaria asociada a la tortuga; 
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Tum 




Turn (-90) 
Pencolor (None) 
Move (20) 
Pencolor White 
Turn (-90) 
Move (10) 

Tum (90) 

Move (20) 


M Figura ¡.—Movimientos típicos de la tortuga (representada por una 
pequeña flecha). En el quinto gráfico se tiene el resultado de la se¬ 
rie de órdenes señaladas al lado. PENCOLOR(NONE) da lugar a un des¬ 
plazamiento sin rastro visible. 


en el primer caso, el animalito se moverá sin dejar rastro (con pa¬ 
rámetros diferentes a WHITE es posible, con un monitor en color, 
trazar líneas en colores). 

Los números señalados entre paréntesis dependen del or¬ 
denador; se expresan en función de la altura y la anchura de la 
pantalla. Una vez familiarizados, gracias al programa de librería 
TURTLE, con las órdenes, en ejecución directa, es la ocasión para 
intentar hacer un programita. Con este fin se debe abaldonar 
TURTLE y volver al menú general de las órdenes, escogiendo esta 
vez la E de Edit: 

PROGRftM printort; 

USES TURTLEGRftPHICS; 

BEGIN 

NOVE(50); 

TURN(120); 

NOVE(501; 

TURN1120); 

NOVE(50); 

REftDLN (* espera return I) 

Es un programa de una banalidad sobrecogedora, cuya ac¬ 
ción, encerrada entre los ''delimitadores" BEGIN y END, consiste 
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en trazar un triángulo de 50 unidades de lado. Pero hemos apro¬ 
vechado para introducir la sintaxis pascaliana. Diremos, ante todo, 
que se admiten mayúsculas y minúsculas, pero que nosotros usa¬ 
remos para distinguir las palabras definidas por el programador 
las minúsculas (alguna vez con la inicial o alguna letra intermedia 
mayúscula). Esto ocurrirá con los nombres de programas, proce¬ 
dimientos y datos (o, como se dice en la jerga pascaliana, "iden- 
tificadores") o bien, con los comentarios (se pueden insertar en 
cualquier punto, delimitados por una pareja de asteriscos: Comen¬ 
tario*). Dos observaciones: una la instrucción READLN provoca 
aquí la espera de que se pulse la tecla Return: en este caso espe- 
cificosirve para mantener la figura en la pantalla, pues de otra for¬ 
ma desaparecería con el END del programa. Segunda observa¬ 
ción: la instrucción USES TURTLEGRAPHICS sirve para invocar el 
correspondiente software de librería (no hay que confundirlo con 
TURTLE, que es un intérprete de las órdenes dadas a la tortuga 
desde el teclado), con el cual el compilador completa el estándar 
del Pascal con las instrucciones de tipo turtle. Por motivos de es¬ 
pacio y sencillez, en los otros ejemplos no insertaremos más USES 
TURTLEGRAPHICS, aunque en los casos reales siempre hay que 
ponerlo, 

Lamentablemente, a diferencia del cómodo BASIC, el Pascal 
es un lenguaje no interpretado y semicompilado: la compilación 
produce un código intermedio llamado "p-code", que a su vez se 
interpreta en el momento de la ejecución (le aconsejamos olvidar 
esto por ahora, pues corre el peligro de confundir las ideas). Afor¬ 
tunadamente, el USCD Pascal prevé una especie de atajo. Termi¬ 
nada la edición y reintegrados al menú de las órdenes generales 
(con la orden O = "Quit”) se podrá escoger la R de R(UN. La pri¬ 
mera vez no es como en el BASIC, y efectivamente, aparece un 
mensaje ("compiling...”) que nos invita a tener paciencia. Necesi¬ 
taremos mucha, especialmente con programas largos, pero si todo 
está sintácticamente O.K., nuestro programa será lanzado y ejecu¬ 
tado automáticamente. En compensación, una vez compilado 
nuestro programa (y guardado en disco), sale en seguida y es 
más veloz que los de BASIC. Así, las complicaciones a las que nos 
obligan los compiladores (dejamos que se imaginen la dura tarea 
de eliminar errores, mucho más complicada que en BASIC, con to¬ 
das las idas y venidas entre Editor y Compilador... ¡pero los hay 
que se divierten con ésto!) quedan compensadas por beneficios 
evidentes. 

Pero al pretender ser éste un curso de introducción, les re¬ 
mitimos a los manuales para todos estos detalles operativos y pa¬ 
samos ya a la sintaxis. Para esto haremos uso de la figura 2, en la 
que rectángulos y círculos expresan las reglas formales del jue¬ 
go, limitadas a las pocas vistas hasta ahora. Se procede con el sis- 
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< programa > 

P>ogram 


| identificador bCK bloque bO 


<bloque> 



<¡nstrucci6n> 



rnrmFigura 2.—Cuadro de la nomenclatura y de las órdenes del Pascal 
vistas hasta ahora. Los símbolos rectangulares encierran cosas a de¬ 
finir posteriormente 

43 


i 











tema top-down; los rectángulos representan cosas aún por preci¬ 
sar en detalle. 

En 1) se dice que un <programa> (el nombre de un objeto 
está encerrado entre paréntesis "angulares 1 ’): <programa>, <blo- 
que>, <instrucción>, etc.) está compuesto por la palabra reserva¬ 
da PROGRAM seguida de un <identifícador>, un punto y coma 
un <bloque> y un punto. Pero, ¿qué es un bloque? Lo aclaramos 
en 2): en esencia es una serie de instrucciones separadas por 
entre las palabra BEGIN y END, Este signo de puntuación (;) es im¬ 
portante en Pascal como ya hemos visto fen 1). 

Pero prosigamos: ¿Qué es un identificado^ tíña serie de le¬ 
tras y cifras cuyo primer carácter tiene que ser una letra. Añadi¬ 
mos que el número de caracteres significativos es ocho. Con 2) y 
3) se entiende fácilmente el significado de las concatenaciones 
simbólicas: las líneas en paralelo que parten de un nudo expresan 
alternativa (lógica OR) y una línea sin símbolos sianifica "posible 
ausencia" —por ejemplo, en 3) la primera letra del identificador 
puede ser también la última—. En cambio, aquellas que vuelven 
atrás denotan posibilidad de repetición o, dicho de una forma cul¬ 
ta, "iteración". 

En 4) (figura 2) tenemos finalmente el resumen de lo poco vis¬ 
to hasta ahora a propósito de instrucciones, con dos pequeños aña¬ 
didos como CLEARSCREEN, para el borrado de la pantalla y el 
rectángulo OTRAS INSTRUCCIONES que nos avisa que todavía 
quedan muchas otras. En cuanto a los rectángulos que contienen 
CONSTANTE INTERNA y VARIABLE INTERNA damos por cono¬ 
cidos sus conceptos desde el curso de BASIC (volúmenes 5 y 7)' 
con instrucciones tipo MOVE (lado) o TURN (ángulo) se loqra una 
mayor flexibilidad 

Acercándonos a las PROCEDURES 

Hagamos aquí algunas observaciones: 

• la sintaxis en Pascal es indudablemente un poco compli¬ 
cada, pero la situación es idéntica en todos los lenguajes 
(el BASIC es sólo más pobre, eso es todo); 

• el símbolo de asignación en lugar de “=” común al BASIC 
y a lenguajes como FORTRAN y COBOL, es ":=" (significa, 
a grandes rasgos, que la variable del primer miembro 
toma" el resultado de la expresión de la derecha), mien¬ 
tras que el "=" queda destinado a las expresiones lógicas; 

• las palabras reservadas (las escrias dentro de semielipses 
en la figura 2, por ejemplo) no se pueden adoptar como 
ídentificadores; 
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• el separador de las instrucciones en Pascal es elúnica¬ 
mente, mientras que el" decreta el fin del programa; 

• la palabra reservada BEGIN es un separador y no va se¬ 
guida de mientras que la asociada END (tiene que ha¬ 
ber exactamente uno por cada BEGIN) requiere el(ex¬ 
cepto si es el último del programa, en cuyo caso pondre¬ 
mos “."), aunque, como compensación, ¡a instrucción que le 
orecede no lo necesita (ver dibujo 2 de la figura 2). Idén¬ 
ticas reglas sobre los valen para otras palabras reserva¬ 
das que funcionan como delimitadores, como FOR, DO, IF, 
ELSE, etc., pero para simplificar no hablaremos ahora de 
ellas, invitándoles a seguir los sucesivos ejemplos. 

En suma, contrariamente a lo que se cree, en Pascal Return, 
espacio en blanco y (comentarios) sirven sólo para separar las pa¬ 
labras, y el programa visto (el único hasta ahora) podría muy bien 
haberse escrito asi. 

PROGRAM Primtort; BEGIN MOVE (50); TURN (120); MOVE 
(50); TURN (120); MOVE (50); READLN (* espera return) END. 

¡Lo importante es que cada punto y'Coma esté en su sitio! Por 
otra parte, los pascalistas nunca hacen semejantes pastiches, es 
más, recurren a las famosas "indentaciones" que caracterizan el as¬ 
pecto de los programas Pascal, como veremos. Peró es hora de 
mostrar algo más serio. 

PROGRAM stardust: 

VAR Escala: INTEGER; 

PROCEDURE estrella(diamens:INTEGER); t 

VAR ind:INTE 6 ER; 

BEGIN 

TURN(-te);(t centrada estrella en tallo ») 

PENCOLOR(WHITE); 

FGR ind:=l to 5 da 
BEGIN 

MOVE(BIAHENS):TURNí144)j 
END; 

TUF:Ní 18) !* tortuga en posición original *) 

END:O Estrella t) 

BEGIN t* programa principal *) 
escala:= 20 ; 

TURN(45):MOVE(escalatB): 
estrella(escalal4 )5 
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MOVETO(0.0> s TURNTD (165); 
HQVE(escalat4)j 
estrel1 a(escala<9) 

MOVETO(0,0);TURNTD(150); 
MOVE (B5cala*¿)¡ 
estrella(escalali) 

END. 


Ei resultado de la ejecución es el trazado de las tres estrellas 
de la figura 3b. 

Veremos en seguida la filosofía de fondo. El programa Star- 
dust se compone de un procedimiento Estrella que es llamado 
tres veces, cada vez con un valor distinto del parámetro "dimens". 
Todo parámetro es una variable cuyo valor se fija de forma ex¬ 
terna al procedimiento, permitiéndole "especializarse" por decir¬ 
lo de alguna manera. En la sintaxis pascaliana la definición está cla¬ 
ra: 


PROCEDURE estrella(dimens:INTESER) 

Esto nos dice que las instrucciones que siguen forman parte 
del procedimiento de nombre Estrella, que tiene un parámetro, en¬ 
tre paréntesis, llamado "dimens". Los dos puntos que siguen a "di- 
mens especifican el "tipo" INTEGER (entero) en el caso en cues- 
tióri Las instrucciones de Estrella son las comprendidas entre el 
B EGIN y el END: un poco más adelante queda claro para qué sir¬ 
ve dimens': MOVE (dimens), seguido de TURN (144) dice que el 
lado de la Estrella puede variar mientras que la rotación es fija, e 
igual a 144 grados. En el programa principal (main) al que, para 
mayor claridad, se le ha adosado el comentario (*programa prin¬ 
cipal*), Estrella es invocada tres veces, cada vez con un valor di¬ 
ferente entre paréntesis.Cuando se llama a una PROCEDURE que 
usa parámetros, en la instrucción de llamada se deberán incluir, 
en cada caso, los valores que queremos tomen los parámetros en 
asi ocasión. Así, por ejemplo, la instrucción Estrella (escala*8) 
"pasa” —realmente se dice así— un valor igual a 8 veces la varia¬ 
ble escala’, al parámetro "dimens" de Estrella. Esta es la manera 
de lograr que el procedimiento Estrella pueda dibujar estrellitas 
de diferente tamaño (Fig. 3). 

Quien sepa BASIC notará la analogía con las GOSUB, salvó 
quo aquí no hay números de línea, los parámetros se pasan des¬ 
de el exterior y la subrutina se invoca directamente por su nom¬ 
bre: realmente es como si se añadiesen nuevas órdenes a la lista 
de instrucciones. 
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PROGRAM Stardust 
VAR:.... 


r 

PROCEDURE Estrella (.. 

VAR:... 



PROCEDURE Hipotet; 
VAR:.. 

BEGIN 



END; (.Hipotet.) 


BEGIN 

TURN (-18) 


END; (.Estrella») 



BEGIN («programa principal») 
Escala: = 20 


END 



Figura 3.-Estructura anidada de un programa Pascal. En a) está in- 
m cluido un procedimiento imaginario Hipóte!, ¡nterno a Estrella. Enb) 
aprecia un dibujo trazado por el programa Stardust incluido en el texto. 
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Estructuras de “cajas chinas” 

Más que analizar detalladamente lo que hace Stardust lo que 
nos urge es comprender su organización. Nos referiremos a la fi- 
tura 3, donde en a) está representado el armazón de Stardust va- 
ciada por así decirlo, de contenidos (como a un cangrejo al que 
se le ha quitado la carne). Es más, a costa de complicar la vida a 
tos lectores, hemos añadido un tercer procedimiento: Hipotet (o 
sea, imaginario), ‘'anidado", a su vez, dentro de Estrella. Es un jue¬ 
go de cajas chinas: el programa principal contiene los procedi¬ 
mientos de pnmer nivel que, por su parte,'pueden contener otros 
de segundo nivel, y así sucesivamente. 

L°s PROCEDURES forman parte de un concepto más amplio: 
el de módulos. Con este término se denominan, además délos pro¬ 
cedimientos, las funciones definidas por medio de la palabra re- 
seivada FUNGTION Su significado es bastante intuitivo. Los pará¬ 
metros (entre paréntesis) que emplean las funciones en su defi¬ 
nición son llamados también “argumentos 1 Se trata de nombres fa¬ 
miliares por poco que sepan de matemáticas. 

Tanto los módulos como el mismo programa global se com¬ 
ponen de dos partes: 

• declarativa, 

• ejecutiva. 

Como sus propios nombres indican la primera comprende to- 
das las declaraciones" necesarias para la correcta interpretación 
del módulo: nombre, parámetros, tipos y variables, en tanto la 
segunda se refiere propiamente a las sentencias u órdenes 
ejecutivas. 

Los cuatro elementos posibles mencionados en la primer no 
están siempre presentes, pero si aparecen deben sucederse exac¬ 
tamente en este orden: nombre (o etiqueta), parámetros, tipos y 
variables para un módulo La regla general prevé la sucesión, en 
el ámbito de un programa completo de Pascal, de las siguientes 
cosas: nombre, constantes, tipos, variables, procedimientos y fun¬ 
ciones. Siempre que se use cualquiera de estos elementos, debe¬ 
rá explotarse previamente en Pascal Para mayor sencillez, nos 
concentramos en las variables. Todas las variables de un módulo 
o del programa entero, tienen que ser declaradas, precisando el 
tipo de antemano y no en el momento en que se van a necesitar 
como ocurre en el BASIC. 

Esto no es una novedad absoluta (también el COBOL prevé 
una apropiada DATA DIVISION). Las variables que siguen a la pa¬ 
labra reservada VAR están dislocadas meticulosamente en el ám¬ 
bito de los módulos a los que pertenecen. 


Este hecho es típico de la concepción jerárquica, base del es- 
tructuralismo. Y no sólo es un hecho formal, sino que afecta al pro¬ 
pio desarrollo del programa. En efecto: 

• una variable definida en un módulo opera también con to¬ 
dos los de nivel inferior; 

• una variable 'local" —adjetivo contrapuesto a “global" en 

esta terminología— sólo opera en el ámbito del módulo en 
que está definida (y eventualmente en aquellas de menor 
nivel) y NO deja huella en el exterior. 

Volveremos a este punto con un ejemplo concreto. Fíjese aho¬ 
ra en que un módulo que contenga otro de nivel más bajo queda 
en la práctica dividido en dos por éste. Así sucede con Hipotet, 
que se interpone entre la parte explicativa de Estrella y la ejecu¬ 
tiva. En particular, esto ocurre casi siempre con el programa prin¬ 
cipal, cuya parte ejecutiva —tendremos que acostumbramos— 
está al final, precedida por todos los procedimientos y funciones 
en juego Indudablemente esto presenta algún problema en el 
caso de programas muy largos: hay que mirar a fondo el listado 
para "visualizar" el trabajo completo, De todas formas no presta¬ 
remos oído a las provocaciones de quienes, acostumbrados al BA¬ 
SIC, en el que las subrutinas generalmente se escriben al final, rea¬ 
licen comentarios desconsiderados Nos limitaremos a observar 
que: 

•' esta redacción (módulos inferiores precediendo a los su¬ 
periores) facilita el trabajo del compilador y, 

los intérpretes, acelera la ejecución (sucede también en 
BASIC, donde bastaría empezar con un GOTO que se sal¬ 
tara las subrutinas escritas al principio); 

• V] realidad, el top-down y en bottom-up (programación as¬ 
cendente) son dos caras del misino problema 


La esencia de Stardust 

Después de todos estos útiles formalismos, volvamos a 
Stardust para describir lo que hace. Comencemos por la 
PROCEDURE Estrella. Para entenderlo, basta con meterse en la piel 
(en este caso caparazón) de la tortuga: después de fijar un ángulo 
de ataque de -18 y de cargar con tinta blanca (WHITE) su pluma, 
dibuja los cinco lados de una estrella de lado "dimens” Probemos 
con el goniómetro o transportador de ángulos: 144 grados es la ro¬ 
tación que hay que realizar para pasar, estando en la punta de una 
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estrella, del final de un lado al inicio del sucesivo. Para ello se sir¬ 
ve de la construcción Pascal FOR, su sintaxis es: 

FOR <indice>:=<nl> TO <n2> DO 
BEGIN 


END O bucle FOR I) 

En lugar de TO se puede usar DOWNTO, en cuyo caso se con¬ 
tará hacia atrás. Se trata, en esencia, de la misma estructura 
(FOR/NEXT) existe en BASIC, aunque con dos limitaciones la 
. Mienta, en el Pascal estándar, sólo puede hacerse con números en- 
teros y el paso (step) es siempre la unidad. Para otras ocasiones 
quedan las construcciones DO-WHILE y REPEAT UNTIL. 

Nos queda ahora el programa principal: es una sucesión nor¬ 
mal de desplazamientos de la tortuga y llamadas a Estrella. Entre 
los primeros aparecen algunos absolutos, mediante las instruccio¬ 
nes MOVETO (x,y) y TURNTO (z), que sirven, respectivamente, 
para alcanzar el punto de coordenada (x,y) o el ángulo "z" del sis- 
lema de referencia de la pantalla, independientemente de la po¬ 
sición actual de la tortuga. 

En cuanto a las llamadas del tipo Estrella (escala*8) se apre¬ 
cia sobre todo la oportunidad de haber introducido la variable glo¬ 
bal "escala": para referir a una misma unidad de medida, el pará¬ 
metro "dimens" También es útil la posibilidad ofrecida por el len¬ 
guaje de pasar una expresión como valor del parámetro: si hipo¬ 
téticamente hubiésemos tenido el capricho de trazar una estrella 
de lado (escala + inc)* 3.14/100, habría bastado escribir: 

estrella descaí a+inc) 13.14 (100) 


Dígalo con flores 

El método de la tortuga, además de tener la ventaja de acer¬ 
car a la informática a gente "pez" en matemáticas, incluso niños, 
l lermite hacer entender que un procedimiento no es siempre y ne¬ 
cesariamente un conjunto de cálculos, sino también un "hacer 
alejo” (muy útil en robótica, por ejemplo). 

Veamos otro sencillo ejemplo: 


PRQ6RAH polígonos; 
VAR escal:INTEGER; 


PROCEDURE poliglnuilad,long,x.y,:INTEEER)j 
VAR iiINTEGER; 

BEGIN 

Í1GVET0 (x Jescal;ylescal)j 
PENCOLQR(WHITE)j 
FDR i:=1 TO nunlad DO 
BEGIN 

MOVE(longtescal); 

TURN(360 DIV nunlad) 

END; 

PENCOLORINONE) 

END;I» polig ») 

BEGIN I» nain *) 
escala: =10 
pol ig(5, 16,-40,-40) ; 
poligdO, 8,30,-40); 
pol ig(30,2,-40,8) 

END. 


No es demasiado difícil darse cuenta de que el procedimien¬ 
to Polig —que tiene cuatro parámetros: numlad, long, x e y— traza 
polígonos regulares de numlad lados, cada uno de longitud long, 
a partir del punto de coordenadas (x*escal, y*escal); lo consigue 
al trazar lados de valor long seguidos de giros de 360/numlad gra¬ 
dos y todo se repite numlad veces, como indica el bucle FOR. Ha¬ 
cemos notar de paso que, para los números de tipo INTEGER (has¬ 
ta ahora no conocemos otros), el Pascal prevé el operador parti¬ 
cular DIV, que proporciona un resultado entero al dividir núme¬ 
ros también enteros (le división entre números reales se hace con 
la habitual barra inclinada o "slash"). 

En cuanto al main, sólo sirve para indicar a Polig los distintos 
valores de los parámetros. Se obtienen figuras que, al aumentar el 
número de los lados (y al disminuir long, pues si no se saldrían 
de la pantalla), se aproximan cada vez más a un círculo. 

Vayamos ahora con la siguiente tarea, que consiste en hacer 
que la tortuga dibuje la planta de la figura 4. Notará en seguida 
que hay varias coincidencias: los pétalos, se repiten varias veces 
y también las flores, todas de cinco pétalos, cada uno compuesto 
por dos arcos. Esto nos sugiere invitar a los más voluntariosos para 
que escriban el programa ellos solos. Una pequeña ayuda: prue¬ 
ben con procedimientos "anidados", teniendo en cuenta que la flor 
está hecha de pétalos que están formadas de arcos. Advertimos 
de todas formas que surgirán problemas algo complicados, aun- 
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que resolubles. ¿Lo han intentado? Comparen entonces su solu¬ 
ción con la siguiente: 

PROGRAM planta; 

VAR escal:INTEGER; 

PROCEDURE petaloüonq;INTEGER); 

PRQCEDURE arca; 

VAR i:INTEGER; 

GEGIN (I arco I) v. 

PENCOLOR(NHITE); 

FOR 1:= 1 TO 10 DO 
BE6IN 

HQVE(lang»e5cal);TURN(9) 

END; 

END;I* arco ») 

BE61N (* petalo ♦) 

TURN(-45)jareo; 

TURN(90)¡arco; 

TURNI135); 

END; U petalo t) 

PROCEDURE flor(dim:INTEGER); 

VAR i¡INTEGER; 

BEGIN <* flor t) 

FOR i:=l TO 5 DO 
BEGIN 

MOVEIdiiiilescal) ¡petalo; 

M0VE(-din*escal);TURN¡72> 

END; 

END;<♦ flor I) 

BEGIN (» iain t) 
escal:=10;PENCDLOR(WHITE); 

H0VET0(0,-60tescal); 

MOVETO(0,-40tescal);TURN(-45); 
petalo(2);TURN(45); 

MOVETO(0,-20*escal)¡TURN(45); 
petalo(2)jTURN(-45); 

M0VET0(0,Q); 

TURNí-45);MDVE(40*escal); 
flor(2); 

MOVE(-40*B5cal);TURN(45); 

MOVETO(0,20tescal);TURN(45); 



NOVE (20tescal); 
flor(1) 

END; 

Los comentarios detallados serían muy largos; le sugerimos 
encarecidamente de nuevo que estudie con detenimiento todos 
los pasos que el programa ha impuesto a la tortuga. El procedi¬ 
miento Arco deriva, imaginariamente, de Polig, aparte del bucle 
FOR; consiste en 10 segmentos girados entre ellos 9 grados, lo 
cual, si reflexionamos un poco, quiere decir 90 grados en total, o 
sea, 1/4 de círculo. Pétalo provocará, por tanto, la siguiente suce¬ 
sión de ángulos (relativos): -45;90 (las 10 veces 9 grados que aca¬ 
bamos de ver); 90 (antes del segundo Arco) y otros 90 (debidos 
a la realización del segundo Arco). Esto da un total de 225, a los 
cuales, antes de salir de Pétalo, se añaden 135 grados, lo que com¬ 
pleta el giro, es decir, una vez trazado el pétalo la tortuga queda 
en la misma situación que cuando lo inició. Todos los módulos si¬ 
guen el criterio de acabar dejando la tortuga orientada exacta¬ 
mente como en la entrada. 



M Figura 4.—Dígalo con flores. La programación modular resulta fácil 
y elocuente con ejemplos tan amenos. 
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PROGRAMA Planta 
VAR escala: INTEGER; 


PROCEDURE Pétalo 
(lortg: INTEGER); 


PROCEDURE Arco 
VAR i: INTEGER 
BEGIN (.Arco») 

ENDT.Arco.) 


BEGIN (.Pétalo.) 
END; (.Pétalo) 


PROCEDURE Flor 
VAR i: INTEGER 
BEGIN (.Flor.) 

END; (.Flor.) 


BEGIN (.main.) 
END 


Figura 5.— Estructura de "cajas chinas" del programa Planta. Como 
se comenta en el texto, no resulta conveniente, como parece a pri¬ 
mera vista, incluir Pétalo en el interior de Flor. No todo es coser y cantar¬ 


la figura 5 contiene las "cajas chinas" con la cuales hemos fa¬ 
bricado el programa Planta. A partir de ahora nos las arreglare¬ 
mos sólo con las indentaciones típicas de los programas Pascal 
(aunque, repetimos, NO obligatorias), que sirven prácticamente lo 
mismo para nuestros fines. Queda un asunto en el aire: ¿por qué 
el anidado de los procedimientos no se ha llevado hasta el extre¬ 
mo que se podría esperar? Y, más exactamente, ¿por qué Pétalo 
contiene a Arco, pero no se incluye en Flor? 

La cuestión es bastante delicada, y para resolverla invitamos 
a imaginar la solución alternativa (que quizá ya haya hecho algu¬ 
no de ustedes). La estructura sería del tipo: 
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PROGRAN plantas 
VAR escaltINTEGER; 


PROCEDURE flor(din:INTEEER); 

VAR i:INTEGER; 

PROCEDURE petalollong:INTEGER!; 

PROCEDURE arco; 

VAR i:INTEGER; 

BEGIN 

END; 

BEGIN (» petalo I) 

i a ■ 

END;(t petalo I) 

BEGIN (I flor t) 

END;(t FLOR »> 

...(seguiría main cono antes)... 

Sin duda se trata de una estructura extremadamente pulcra 
y elegante y, efectivamente, el profesor Bowles la propone en su 
libro, pero para trazar una o más flores completas solamente. 
Nosotros, en cambio, queríamos resolver toda la tarea trazando 
otros pétalos (en este caso hojas) aislados. ¿Sería lícito, en estas 
condiciones, invocar Pétalo en el main? La respuesta es negativa, 
Pueden probar a compilar la nueva versión: el compilador se blo¬ 
queará, negándose a proseguir, precisamente al llamar a Pétalo. 
El motivo está en la estructura jerárquica del proceso de copipi- 
lación. De aquí se deriva la Regla siguiente: 

LOS PROCEDIMIENTOS "VISIBLES" PARA UN CIERTO NIVEL Y 
LOS UNICOS A LOS QUE PUEDE LLAMAR SON AQUELLOS DE SU 
MISMO NIVEL O LOS DE NIVEL INMEDIATAMENTE INFERIOR 
CONTENIDOS EN EL. 

En ocasiones, un procedimiento puede invocarse a sí mismo 
o a procedimientos de nivel mayor.,., pero éstos son detalles de 
los que hablaremos más adelante. Con el último planteamiento vis¬ 
to del main se puede invocar sólo Flor, desde flor sólo Pétalo y 
desde éste Arco Nosotros, en cambio, necesitábamos poder lla¬ 
mar a Pétalo en el main, así que lo hemos hecho parejo en "dig¬ 
nidad” a Flor. La solución será, quizá, menos bonita, pero funciona 
perfectamente (el programa de Bowles sirve para Flor pero no 
para la Planta entera...). 
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De esto se puede obtener una pequeña moraleja: aunque el 
anidar puede ser útil para aumentar la claridad, acercarse ál "di¬ 
vide et impera", y en ciertos casos, proteger un procedimiento in¬ 
terno, haciéndolo de uso "exclusivo" de aquel en el que está con¬ 
tenido otro (podría ser el caso de Arco). En general se aconseja 
mantener sólo dos niveles, el del main y otro más en el que se 
incluirán todos los demás procedimientos. 

Por último, observe que la VARiable "i" está definida en dos 
procedimientos distintos. Cosas como ésta, que suscitan la curio¬ 
sidad y que piden explicaciones, las ablararemos en el próximo 
capítulo (a veces es necesario un poco de suspense). 



PROFUNDIZANDO CON LA TORTUGA 


Otros formalismos útiles 


l~ 1 programa Planta del capitulo precedente se 

prestaba a varias reflexiones Ante todo hay que 
afirmar que anidar los procedimientos “hasta el 
m final" no es siempre bueno ni, por supuesto, obli- 

ImH Muchas veces, sin embargo, este plantea- 

MixKU miento se impone por su elegancia, desde lue- 
/jgo se corresponde mejor con la filosofía del "di- 
vide et impera", que consiste en subdividir me¬ 
diante niveles jerarquizados, un problema complejo en subpro¬ 
blemas cada vez más sencillos: Planta, que está formada por Flor, 
que está formada por Pétalo... Hemos aprendido que un procedi¬ 
miento se convierte en algo privado del procedimiento situado in¬ 
mediatamente por encima (algo así como las variables locales), 
con lo que no se le puede llamar desde niveles aún más externos: 
esto da lugar a algunos problemas. 

En cuanto a los datos, hay que distinguir entre globales y lo¬ 
cales. De esta sutil distinción dependen aspectos como la seguri¬ 
dad y la comodidad. La seguridad deriva sobre todo del hecho 
de que se elimina el peligro de que las variables necesarias sólo 
dentro de un procedimiento puedan ser influidas por el exterior, 
por despiste o dejadez. Imaginemos, por ejemplo, que hemos és- 
crito en BASIC un subprograma y que queremos reutilizarlo en 
otro sitio: debemos tener mucho cuidado con los nombres de las 
variables, pues en BASIC son todas globales. En segundo lugar, y 
dado que un dato local no deja rastro en el exterior del bloque 
en el que está definido, o más exactamete, en los bloques de ni¬ 
vel superior, mientras que en general es váiido en todos los de 



















nivel inferior contenidos en el bloque de definición, un mismo 
identificador puede usarse en procedimientos distintos; así no en¬ 
loqueceremos buscando nombres de datos. 

En el ejemplo del capítulo anterior esto se aplicaría al índice 
“i", usado tanto en el procedimiento Arco como en el Flor. La va¬ 
riable "i” de Arco y la "i" de Flor son homónimas, pero diferentes, 
puesto que la primera sólo sería utilizable por Arco y Pétalo (que 
contiene a Arco), pero no fuera. El compilador les asigna áreas de 

memoria distintas. Remachemos este punto con un nuevo ejemplo. 

s. 

PROGRAM telescop; # 

VfiR s:STRIMG;1 iv¡1NTEBER; 

PROCEDURE priaera; 

BEGIN 

liv;=liv+l¡ 

WRITELN (’ ’:liv!2, 7 coaienza la priaera’); 

WRITELN (’ ’;livl2,s>; 

WRITELN (’ ’:1 ivt2,’ acaba la priaera’l; 

1 iv:=liv-l 
END;(» prinera ») 

PROCEDURE segunda; 

VAR s:STRIN5; 

BEGIN 

liv:=1iv+1; 

WRITELN (’ ’:livl2,’ coaienza la segunda’); 
s:=’¡cucu.soy la segunda!’; 

WRITELN (’ ’¡livl2,s); 
prinera; 

WRITELN (’ ’ilivl2,’ acaba la segunda’); 

1iv:=Iiv-1; 

END;(I segunda 1) 

PROCEDURE tercera; 

BEGIN 

1iv;=liv+1; 

WRITELN (’ ’¡liv$2,’ coaienza la tercera’); 
s;=’¡aira que bonito!’; 

WRITELN (’ ’:livl2,s); 

WRITELN (’ ’:livt2,’ acaba la tercera’); 
liv;=liv-l; 

END; (t tercera t ) 

BEGIN !! aain t) 
s:=’prograaa principal’; 



1iV!=0 
NRITELN Is); 
primera;WRITELN (s); 
segunda;WRITELN (s); 
tercerajWRITELN (s); 
END. 


Dado que en este libro, dedicado a los principios básicos, 
no hay espacio para un tratamiento sistemático completo, vamos 
explicando ciertas reglas a medida que se van presentando. 
WRITELN es el equivalente al PRINT del BASIC; concluye con un 
RETURN. También se utiliza la instrucción WRITE, que funciona de 
la misma forma, pero sin el Return final. En el Pascal UCSD dispo¬ 
nemos del tipo STRING (cadena), ausente en el Pascal estándar. 
Una constante de cadena se encierra entre apóstrofos (') en lugar 
de las comillas del BASIC (entre paréntesis). Los objetos a impri¬ 
mir se sitúan ya sean variables o constantes. Los dos puntos se¬ 
guidos de una expresión indican la longitud del campo, en el que 
va justificado por la izquierda el elemento que les precede: así 
WRITELN(‘ ':Liv*2, 'comienza la primera’) hará preceder la expre¬ 
sión “Comienza la Primera", de tantas parejas de espacios (' ’) como 
le indique Liv* 2 . Esto servirá para hacer evidente, con la oportuna 
indentación, el nivel en que nos encontramos y, a tal fin, la varia¬ 
ble Liv (nótese que es global) será incrementada y decrementa- 
da a la entrada y salida de los tres procedimientos. Llegados a 
este punto, invitamos al lector a imaginar lo que hace el programa. 

Si lo que ha pensado coincide con lo que sigue, ¡felicidades, 
acertó!; 

t 


Programa principal 
Comienza la primera 
Acaba la primera 
Programa principal 
Comienza la segunda 
¡Cucú, soy la segunda! 
Comienza la primera 
Programa principal 
Acaba la primera 
Acaba la segunda 
Programa principal 
Adelante tercera 
Mira que bonito 
Acaba la tercera 
Mira que bonito 
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Seguramente incluso quien haya seguido paso a paso y es¬ 
crupulosamente el programa, se habrá encontrado con alguna sor¬ 
presa. La razón de esta extraña apariencia reside en el hecho de 
que la "s" es global y actúa en el main como en todos los proce¬ 
dimientos excepto en Segunda, en donde tenemos con el mismo 
nombre una variable local. Por lo tanto, la cadena global "s" per¬ 
manece inactiva (ignorada y "en suspensión") dentro de Segunda, 
y vuelve a funcionar en cuanto se entra en un bloque en el que 
"s" no es local. Se puede ver incluso que cuando llamamos desde 
Segunda a Primera el valor de "s" que imprime no es el espe¬ 
rado "¡Cucú, soy la segunda", sino "Programa principal", y ocurre 
esto porque en Primera "s" vuelve a ser la global, desactivada tan 
sólo en Segunda. 

Es muy importante dominar por completo este funcionamien¬ 
to: corresponde a un mecanismo preciso del compilador que. 
cuando llega a una instrucción, busca la variable en primer lugar 
en la lista de las variables locales; si encuentra la que está en jue¬ 
go en la instrucción, se da por satisfecho, y sólo en caso contrario 
mira en los módulos de nivel superior a los que pertenece (no en 
los demás) y, en último extremo, en la lista de variables globales. 
Espero que ya esté todo claro, especialmente el por qué con la 
última instrucción del main se escribe 'Mira qué bonito' (el pro¬ 
cedimiento Tercera no tiene “s" como variable local y, por tanto, 
actúa sobre la "s" global. 

La ocasión es propicia para prevenir posibles críticas por par¬ 
te de los BASICalistas empedernidos, invitando, sobre todo a los 
principiantes, a no exagerar con los refinamientos de la progra¬ 
mación en Pascal, para evitar malentendidos. En concreto, esto se 
puede "traducir" como: 

• no usar demasiados niveles, adoptándolos sólo allí donde 
resulten lógicos y funcionales; 

• distinguir al máximo (y en caso de duda conviene recurrir 
a nombres distintos .) entre variables locales y globales. 

Otros elementos del mosaico: Jas construcciones 

Ha llegado el momento de tratar de las estructuras de control 
(releer los capítulos 1 y 2 puede ser oportuno). 

En la figura 1 están dibujados los elementos sintácticos del ci¬ 
clo FOR (ya visto) y de los famosos WH1LE y REPEAT. Como se 
puede apreciar (diagrama 4), por Instrucción Compuesta se en¬ 
tiende una serie de instrucciones elementales (llamadas en inglés 
"statement") separadas por el habitualy delimitadas por los fa¬ 
miliares BEGIN y END. La'estructura REPEAT, en cambio, prescin- 
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RINCIPI 


RINCIPII 


Condición 


Instiucción 


Verdadera 


.Verdadera. 


Instrucción 

oompuesta 


Condición 


FINAL 


FINAL 


Ciclo WHILE 


Ciclo REPEAT 


M Figura 2.—Diagrama de flujo de las estructuras cíclicas WHILE y 
REPEAT en Pascal. Recuerden que con el primero se sale cuando 
la <condición> es falsa y, con el segundo, cuando la <condición> es ver¬ 
dadera. 


de de ellos (esto pasa en Pascal; en otros lenguajes estructurados 
hay mayor uniformidad al respecto). En efecto, el padre del Pas¬ 
cal, Niklaus Wirth, decidió que las palabras REPEAT y UNTIL cons¬ 
tituían buenos delimitadores "naturales". 

En la figura 2 tenemos los organigramas de las dos construc¬ 
ciones WHILE y REPEAT, Son equivalentes y siempre se pueden 
sustituir una por otra. 

Ha aparecido en la figura 1 un término (expresión booleana) 
que es oportuno aclarar. En la jerga se llama booleana a un tipo 
estándar de variable capaz de tomar sólo dos valores: TRUE (ver¬ 
dadero) y FALSE (falso), palabras evidentemente reservadísimas. 
El adjetivo "booleano" se usa en honor a George Boole, inventor 
del Algebra del mismo nombre. Este adjetivo caracteriza en Pas¬ 
cal una variable lógica, de la siguiente forma: 

VAR lapalis:BOOLEAN; 


y después de esto, una posible asignación de esta variable, seria: 


lapalis;=la>b) DR NQT (a>b) 


Pregunta, ¿qué valor (booleano) asumirá lapalis según la con¬ 
dición anterior? Es evidente que TRUE, independientemente de 


los valores asumidos por a y b; o es cierta una condición o la otra, 
no hay escapatoria. Las "reglas del juego" de la expresión boolea¬ 
na, en Pascal, son las mismas que en el BASIC, es decir: 

• las condiciones elementales están expresadas por compa¬ 
raciones (con simbología idéntica: >,<=,>=,<=<>); 

Las comparaciones deben hacerse entre tipos homogéneos: 

• el símbolo = en Pascal no se puede confundir con el de 
asignación, que, como se ha visto, está precedido por dos 
puntos; 

• se pueden usar los operadores lógicos AND, OR y NOT. 

Veamos ahora un par de ejemplos con la tortuga y, en parte, 
con las cadenas del UCSD Pascal. Este es el primero: 

PROERAH «hilegrfj 

VAR long,ang,incr:INTEBER; 

resp:CHAR; 

PROCEDURE iniscrn; 

BE6IN 

CLEARSCREEN;PENCOLDR(WHITE) 

END; 

PROCEDURE proxlin; 

BEBIN 

HOVE(long)¡TURN(ang); 
long:=long+incr 
END; 

BEBIN (taain t) 
iniscrn; 

WHILE IrespO’F’) AND (respO’P) DO 
READLN (ang);READLN(incr>; 
long:=5; 

WHILE IDng<=150 DO proxlin; 

READ (resp); 
iniscrn; 

END; 1* WHILE «ayor ») 

END. 

Este programa sirve para trazar un típico dibujo de los gráfi¬ 
cos de Tortuga, como el de la figura 3 (corresponde a un ángulo 
= 89 grados). Variando los parámetros "ang" e "incr" introducidos 
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se podrán ver infinidad de resultados (son interesantes ángulos 
como: 59, 60, 61, 72, 73, 119/120, 121, 135, 144, 154, etc ). Quien dis¬ 
ponga de un ordenador y se quiera divertir, puede hacer lo si¬ 
guiente: ante todo, insertar después de la línea PROGRAM el in¬ 
dispensable USES TURTLEGRAPHICS y sustituir CLEARSCREEN 
por INITTURTLE. El main está compuesto por dos ciclos WHILE 
anidados uno en otro. El exterior toma los parámetros "ang" e "incr" 
y, al final, "resp". Este es un dato de tipo CHAR, es decir, carácter, 
por lo que el READ equivale al GET de BASIC. Como resulta evi¬ 
dente (y es ésta la razón tanto de WHILE-coroo de REPEAT) el pro¬ 
ceso se repite "mientras" (while) la respuesta (''resp' 1 ) sea distinta 
de fin (F mayúscula o minúscula). Una pregunta: la condición (resp 
<> ’F') AND (resp O T) es correcta, pero sustituyendo AND por 
OR, el ciclo no acaba nunca. ¿Sabría decirnos por qué? Si no se 
pulsa F ni f (un simple RETURN, por ejemplo) se llama al proce¬ 
dimiento Iniscr de limpieza de pantalla. En cambio, el bucle más 
interno ejecuta repetidamente Proxlin, que consiste en trazar lí¬ 
neas de longitud creciente (en un valor incr) seguidas de un giro 
de "ang 1 ' grados hasta que "long" supere 150. 



Tome nota de que el WHILE más interno no ha requerido los 
delimitadores BEGIN y END porque, como suele ocurrir en otros 
lenguajes, comprende una sola instrucción: Proxlin. 

Una última observación: lo espartano del diálogo hombre- 
máquina es también debido al hecho de que, introduciendo la 
tortuga, se va a página gráfica, por lo que instrucciones tipo 
WRITELN ("Dame el ángulo”) no aparecerían en la pantalla de mu¬ 
chos ordenadores personales,, a menos que no se introdujeran ins¬ 
trucciones de restablecimiento de modo texto/modo gráfico 
(TEXT MODE y GRAFMODE en el Pascal UCSD del Apple) que 
complicarían innecesariamente el ejemplo. 

REPEAT, IF THEN/ELSE y equivalencias 

Al ilustrar ahora la construcción REPEAT, aprovecharemos 
también para introducir la estructura IF/ELSE, muy conocida y pre¬ 
sente én muchos BASIC. 

La idea original del algoritmo base del siguiente programa se 
remonta al célebre Martin Gardner, de la revista "Scientific Ame¬ 
rican", y consiste en transformar una cadena de caracteres 'S' y ’D' 
en figuras obtenidas haciendo girar la Tortuga +90 ó -90 grados 
en cada uno de los casos. Para complicar las cosas hemos añadi¬ 
do la posibilidad de que el usuario pida la repetición del trazado 
y de que elija ángulos diferentes de 90. Los dibujos obtenidos 
son del estilo de los mostrados en la figura 4: en a) con la limita¬ 
ción de Gardner y en b) con la flexible extensión a ángulos cua¬ 
lesquiera. 

PR06RAN figuras} ( 

VAR sec:9TRING;car:CHAR; 
din,ang,i:1NTEGER; 

BEGIN 

MRITE ('¿disensión? ’);READLN (di«); 

KR1TE ('¿ángulo? ’)¡READLN (ang); 

«RITE ('¿secuencia? ’);READLN (sec); 

CLEARSCREEN;PENCOLQR(«HITE)¡ 

REPEAT 

i:=l; 

REPEAT 

NOVEldiJtli); 

IF SEC(i)=’S’ THEN TURN(ang) 

ELSE TURNI-ang) 
ii=i*lj 
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UNTIL i)LENBTH(sec); 

REñDícar) (I NOTft: Return acaba la sesión de dibujo *) 
UNTIL car=CHRU3> 

END. 


Se trata de uno de esos casos en los que el programa habla 
por sí mismo, es casi autoexplicativo: hasta que (until) el usuario 
no apriete la tecla Return (de código ASCII 13) la tortuga repite 
el trazado (recomenzando con i:=l) de la figura (Gardner utilizaba 
el término "spirolateral"). Si no acaba con la "tortuga en la misma 
posición que al inicio, cada una de las repeticiones se convertirá, 
en realidad, en fragmento de otra figura mayor. La figura "nace" 
de la interpretación de la cadena sec, cuyos caracteres son exa¬ 
minados, uno a uno, con la instrucción sec(i), determinando giros 
a derecha o izquierda y repitiéndolos hasta...; ¡bueno, no vamos a 
repetir lo que, en el fondo, se dice y repite en el programa mis¬ 


M Figura 4.—Figuras obtenidas partiendo de un algoritmo ideado por 
Martin Gardner En a) se sigue su idea primitiva (ángulos de ± 90 
grados); en b) se representan ejemplos de la variante de Bowles (cual¬ 
quier tipo de ángulo). 


mo! Haremos sólo unas observaciones formales sobre los elemen¬ 
tos pascalianos introducidos a hurtadillas: 

• el tipo CHAR es, obviamente, un carácter; 

• WRlTE( algo’) seguido de READLN(x) equivale a INPUT 
"algo”, x del BASIC, y WR1TE, contrariamente a WRITELN, 
no manda a principio de línea el cursor; 

• sec(i) funciona en una cadena como el MID$(SEC$,I,1) dán¬ 
donos el iésimo carácter de la cadena; 

• también LENGTH (cadena) y CHR(n) funcionan del mismo 
modo que las funciones análogas en BASIC dan la lon¬ 
gitud de la cadena y el carácter correspondiente al códi¬ 
go ASCII n. 

Y veamos ahora el problema de la equivalencia entre REPEAT 
y WHILE, que ya sabemos garantizada por el teorema de Jacopim 
& socio. 

En casos como los dos que mostramos a continuación (gene¬ 
ración de los cuadrados de 1 a 100...) es banal: 


x:=0; xs=0¡ 

MH1LE y<100 DO REPEAT 

BEEIN x:*x+1; 

x:=x+l; v:=x*x; 

ys=xtx; 


Observe que la condición y<100 del WHILE se ha cambiado 
por y>~100 en el REPEAT. Esto sucede porque el test se hace en 
un caso al principio y en otro al final, y por la semántica difer'ente 
de WHILE y REPEAT (vuelvan a estudiar la figura 2). 

Pueden darse, sin embargo, situaciones de relativa ambigüe¬ 
dad. 

Supongamos que tenemos: 

READLN(x,y> 

HHILE x>=y DO 
BEEIN 
elab(x.y) 

END; 

donde Elab(x,y) sea un procedimiento que manipula "x" e "y", 
transformándolos de forma imprevisible (Elab podría contener, 
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por ejemplo, la lectura de una nueva pareja x,y), de forma que no 
sabemos a priori cuando se conseguirá la condición prevista. Aho¬ 
ra bien, el ciclo WHILE, con el test al principio, podría no realizar¬ 
se ni siquiera una vez; así, una trasposición precipitada al ciclo RE- 
PEAT, que tiene el test al final, podría resultar errónea. La correcta 
será la siguiente: 

READLN(x,y) 

IF x>=y THEN REPEAT 

elab (x, y); ^ > 

UNTIL ¡KY 

No hace falta, empero, ser muy puristas para encontrar esta 
solución poco elegante. Veamos un ejemplo totalmente formal del 
caso contrario: 

REPEAT 
I1;I2;...¡In 
UNTIL <C0NDIC> 

Donde Il...Im son instrucciones genéricas. 

Para hacer algo perfectamente equivalente con WHILE ten¬ 
dremos: 


II;12;...;In 
WHILE <C0NDIC> DO 
BEGIN 

II;12;...;In 
END; 

Nótese que <condic’> es, generalmente, la negación de <con- 
dic>. Ahora bien, si las instrucciones ILIfr forman un conjunto 
abundante (con bastante código), su duplicación resultará, por lo 
menos, antieconómica. Se podría evitar adoptando una variable 
auxiliar booleana (como puede ver, volvemos a la problemática 
del capítulo 2): 

sm:=TRUE; 

WHILE <C0NDIC> OR sn DO 
BEGIN 

11; 12;...;In; 

sh:=FALSÉ 

END¡ 


En el primer ciclo, el switch sw (desviador), al ser Verdadero, 
fuerza la primera ejecución. Al acabar ésta, le damos a SW el va¬ 
lor FALSE (falso), con lo cual, que se realicen o no más ciclos de¬ 
penderá sólo de <condic>. 

Está claro que, según las ocasiones, unas veces REPEAT será 
más cómodo que WHILE y otras ocurrirá al contrario. También la 
presencia del bucle FOR es útil, aunque las limitaciones ya vistas 
nos obliguen, a veces, a recurrir a WHILE o REPEAT para lograr 
un incremento/decremento no unitario. Hay también algunos tru¬ 
cos para lograr esto sin usar las mencionadas estructuras: por 
ejemplo, un equivalente a un bucle BASIC de tipo: 

FDR X=0.1 TD 10 STEP 0.1 
se puede hacer en Pascal así: 

x: =0 

FOR i:=1 TO 100 DO 
BEGIN 
x: =x +0.1 


END; 


Funciones, procedimientos y sus relaciones 

Como ya comentamos previamente, en Pascal, además de los 
procedimientos, existen las FUNCTION. Su finalidad, a diferencia 
de los primeros, es restituir al programa (o subprograma) que las 
llama un valor evocable a través del nombre de la propia función. 

Como de costumbre, vamos a dar en seguida un par de 
ejemplos: 

PRD6RAH cilindro; 

VAR volu#en,r,h:REAL; 

FUNCTION areacíre(r:REAL):REAL; 

C0NST pi=3.14159265; 

BEGIN 

areacirc:=rtrtpi 

END; 

BEGIN U saín t) 

READLN (r); 

WHILE r>=0 DO 


68 


69 











BEGIN 

READLN(h); 

voluaen:=areacirc(r)lh; 

WRITE (’el cilindro de radio ’,r,’ y altura ’,h)¡ 

WRITELN ('tiene un volueen ’,volu*en); 

READLN(r) 

END; 

END. 

Hemos aprovechado el ejemplo para introducir otro tipo de 
dato, el REAL, cuyas características pueden encontrar en anterio¬ 
res volúmenes de la BBI (son números reales, por ejemplo, 10,3.14, 
8.1697, etc.). También hemos introducido otro elemento sintáctico: 
CONST, que declara como constante el nombre que le sigue (en 
nuestro caso "pi") y fija su valor (3.14159265), "pi" será desconoci¬ 
da fuera de la FUNCTION Areacirc. Dese cuenta de que se utiliza 
el signo = en lugar de := por cuanto se tiene identidad pero no 
asignación. 

Este ejemplo es tan sencillo que su funcionamiento para el 
cálculo de volúmenes de cilindros se deja enteramente a la com¬ 
prensión del lector. En esencia nos ha servido para introducir la 
sintaxis de FUNCTION y para hacer notar que en ella, a diferencia 
de lo que sucede con un procedimiento, el nombre de la función 
se conduce, en una expresión, como una variable, que puede uti¬ 
lizar de forma directa el programa que la llama. Esto podría inclu¬ 
so realizarse con un WRITELN; en el caso visto, se habría podido 
hacer lo siguiente: 

WRITE (’el cilindro de radio ’,r,’ y altura \h)¡ 

WRITELN ('tiene un val unen ’.areacircth); 

En otro caso, suponiendo que Prisma, Pirámide y Esfera sean 
otras FUNCTION, el volumen total de un compuesto sólido sería 
dado por una expresión de este tipo: 

voltot:=prisna(bl,b2,hl)+píra*ide(b3,b4,h2)+esfera(r) 

formado por ellas (admitiendo que la esfera se sostuviera en la 
punta de la pirámide). 

Muchas veces es posible obtener con los PROCEDURES algo 
. muy similar a FUNCTION. No es un juego de palabras; por ejem¬ 
plo, en nuestro caso hubiéramos podido recurrir a la variante si¬ 
guiente: 

PROCEDURE calcarea(rag:REAL;VAR areacirc:REAL) 


Pero cuidado: después hay que modificar también la decla¬ 
ración de las VAR en el main. Se puede hacer así: 

PROERAH cilindro; 

VAR voluBen,areacirc,r,h;REAL; 

De esta forma logramos que Calcarea devuelva, dependien¬ 
do sólo del parámetro rad el resultado Areacirc. Entonces, ¿que- 
da todo lo demás como antes? No exactamente. Tal y como diji¬ 
mos antes, de esta forma podemos lograr “algo” parecido a una 
FUNCTION, pero su comportamiento y manejo serán distintos. Asi 
será necesaria también una modificación posterior. 


READLNlh) 

calcarea(r,areacirc);volu«en¡=areacireth; 


Sequramente la mayoría de ustedes ya se esperaban algo pa¬ 
recido, por lo menos los más atentos, pues recordarán que un pro¬ 
cedimiento debe ser llamado explícitamente, con sus parámetros, 
para ser ejecutado. Lo que sí puede haberles pillado de sorpresa 
es la presencia de Areacirc junto al parámetro r . En efecto, Area¬ 
circ es, al mismo tiempo, un parámetro y un resultado. Para poner 
un poco de orden en esta delicada materia debemos aclarar que, 
r-hav ríns tinos nnsibles de Darárnetros: 


• parámetros llamados “como valor”, 

• parámetros llamados "como referencia" (o "por situación ) 


También se les llama, respectivamente, parámetros-valor y 

parámetros-variables. , , 

Los primeros son como rad, y los segundos son del tipo de 
Areacirc y se distinguen de los primeros por estar precedidos en 
su definición de la palabra VAR. La diferencia esencial entre ellos 
es que los primeros sólo son argumentos, mientras que ios segun¬ 
dos pueden ser también funciones. 

Pero ambos son parámetros y, por lo tanto: 


• hay que pasarlos al procedimiento, 

• pueden tener nombres distintos en el main y en el proce¬ 
dimiento. 

Para entendemos mejor, supongamos que el ejemplo prece¬ 
dente sea un poco más complicado y se tengan que calcular los 
volúmenes de tres cilindros distintos de radios rl, r2 y r3, y alturas 
h 1, h2 y h3. Incluimos en las VAR del main no sólo estas seis nue- 
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vas variables, sino también areal, area2 y area3. Intente, sabiendo 
esto, escribir la llamada correcta a Calcarea para calcular el volu¬ 
men del segundo cilindro (suponemos que "volumen" es una va¬ 
riable de trabajo usada para los tres cilindros). Sería: 

cal carea(r2,area2);vDlu«en:=area2ih2; 

Es decir, que la elección de Areacirc como nombre común 
para el main y el procedimiento era legítima, (no producía moles¬ 
tias), pero, ciertamente, no vinculante. 

Veamos un caso simple, pero interesante; para aclarar otros 
cuantos conceptos: 

PROSRftfl ejenplo; 

VAR x,y,z:INTEGER , 

PRDCEDURE contador(VAR n:INTEGER;incr: INTEBER); 

BEGIN 

n:=n+incr 

END; 

BEGIN (* main *) 

x: =0;y:=2;z:=1¡ 

WHILE x<12 DO 
BEGIN 

contador(x^z); 
cantador(y,x); 
contador(z,y)j 
END; 

END. 

¿Después de cuántas vueltas se sale del bucle WHILE y con 
qué valores de "x”, "y", y "z"? Si lo hace verá que tras dos vueltas 
y con valores 17, 25 y 37 (basta un poco de paciencia para com- 
Probarlo). A mitad de camino puede suceder, por ejemplo, que 
"x'j "y" y "z” valgan 1, 3 y 4, después de lo cual, al llamar a Con- 
I.hIoi (x,z) a "x” se le añade "z", "pasada" como incr a Contador, 
i (lie devuelve una "x" modificada igual a 1 + z = 5. 

I n resumen: en una PROCEDURE los parámetros usados como 
i'flomncia son empleados para facilitar los resultados obtenidos 
"ii l.i PROCEDURE al programa o subprograma que realizó la 11^- 
ii mi l.i y que determinó los parámetros de valor. 

Otra ventaja de los procedimientos respecto de las funciones 
"■' l 'I 11 " permiten la realización de funciones con salidas múltiples. 

: i'Mo :iorá necesario definir más parámetros de tipo VAR. Por ejem- 
I ’l" (y sin más comentarios): 


PRDCEDURE «ulttune(x,y,z:REAL;VAR í 1,Í2:REAL); 

Hay una última diferencia entre FUNCTION y PROCEDURE, 
pero es un tema delicado que lo dejaremos para más tarde. 


Otras aplicaciones de FUNCTION e IF THEN/ELSE anidadas 

A pesar de lo anterior, muchas veces se pueden obtener 
cosas elegantes con una FUNCTION, además de instructivas, He 
aquí una: 

PRD6RAM preguntas; 

VAR trabajo.11uvia:B00LEAN; 

FUNCTION si:B00LEAN; 

VAR resp:CHAR; 

BEGIN 

READLN(resp); 

IF resp=’S’ 0R resp=’s’ THEN 
si:=TRUE 
ELSE 

si:=FALSE 
END;(I si ») 

BEGIN II aain t) 

WRITELN (’i despierta!’);HRITELN; 

«RITE ('¿casado desde hace «as de 5 anas? ’); 

IF NOT si THEN WRITELN ('besa a tu nujercita’); * 

«RITE (’¿dia laborable? ’);trabajo:=si; 

«RITE ('¿llueve fuera? ’);lluvia:=si¡ 

(I Se podrían añadir «uchas «as preguntas i) 

IF trabajo THEN 
IF lluvia THEN 

WRITELN Cal trabajo en coche’) 

ELSE 

WRITELN Cal trabajo a pie; isienta bien!’) 

ELSE 

IF LLUVIA THEN 
WRITELN fquédate en casa’) 

ELSE 

WRITELN ('vete a jugar al tenis’) 

END. 
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La curiosa FUNCTION sí (sin parámetro esta vez; no hace fal¬ 
ta) permite recoger la respuesta y transferir su resultado (lógico) 
a una expresión IF, Esto ocurre con la pregunta inicial, que se so¬ 
luciona en seguida con beso o no beso. En cambio, en las pregun¬ 
tas siguientes se ha recurrido a variables booleanas temporales 
(trabajo y lluvia) para permitir, más adelante, el barrido casuístico. 

Este programa nos ofrece la oportunidad de realizar algunas 
aclaraciones útiles sobre la estructura IF THEN/ELSE cuando apa¬ 
rece anidada. Dado que la primera regla es el sentido común, hay 
que tener en cuenta que: 

• tanto IF como ELSE hacen de separadores (como BEGIN, 
END o mejor, como REPEAT, UNTIL); 

• en los casos de instrucciones múltiples, las inherentes a 
una misma IF estarían encerradas entre dos separadores; 
si no habría problemas (errores lógicos o malentendidos 
con el compilador). 

Un ejemplo clásico de incomprensión entre la intención del 
programador y la interpretación que de él realiza el compilador 
se presenta con la llamada IF "abreviada 11 , o sea, sin ELSE. 

Supongamos que en nuestro programa, por algún extraño mo¬ 
tivo, se quiere eliminar la respuesta 'al trabajo a pie' (porque la ofi¬ 
cina está demasiado lejos, por ejemplo). El principiante pensaría 
que es muy fácil y lo modificaría así: 

IF trabajo THEN 
IF lluvia THEN 

HRITELN (’al trabajo en coche’) 

ELSE 

IF LLUVIA THEN 

HRITELN (’quédate en casa’) 

ELSE 

HRITELN (’vete a jugar al tenis’) 

END. 

Ahora bien, indicando las dos respuestas posibles con S y N, 
¿qué salida dará ahora el programa en los cuatro casos posibles? 

Intenten adivinarlo y compárenlo con lo que sigue: 

SS-'al trabajo en coche' 

SN-'vete a jugar al tenis' 

NS y NN-NINGUN MENSAJE!!! 

¿Sorprendidos? En el segundo caso el mensaje es inmoral (ir 
al tenis en día laborable porque hay sol), mientras que en los dos 
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últimos no hay respuesta. El hecho es que el compilador no hace 
el más mínimo caso de las indentaciones que utilicemos y asocia 
cada ELSE a la última IF que encuentra. ¿Y si se trata de IF sin 
ELSE? No se escandaliza y ejecuta solamente la primera instruc¬ 
ción que encuentra después de la cadena IF; se trata precisamen¬ 
te de la IF "abreviada" (utilizada ya en el caso del beso a la mu¬ 
jer). Veamos, para satisfacer a todos, los diferentes casos detalla¬ 
damente: 

• SS. Funcionan las dos primeras IF, mientras que la primera 
ELSE provoca el salto hasta END; 

• SN. La primera ELSE se toma, también aquí, como alterna¬ 

tiva a la lluvia, después de lo cual la nueva IF lluvia da vida 
a la otra ELSE, de aquí la respuesta; z . 

• NS y NN. No hay ningún mensaje, porque no verificándo¬ 
se trabajo, se salta directamente a END. Si reflexiona des¬ 
cubrirá fácilmente que todo depende de que el compila¬ 
dor asocia, en todos los casos, la primera ELSE a la segun¬ 
da IF. 

¿Cómo podríamos remediarlo? Hay dos posibles soluciones 
para problemas de este tipo. La primera consiste en recurrir a ex¬ 
presiones booleanas: 

IF trabajo AND lluvia THEN 

HRITELN (’al trabajo en coche’) 

IF NOT trabajo AND lluvia THEN 
HRITELN ('quédate en casa’) 

IF NDT trabajo AND NOT lluvia THEN t 

HRITELN (’vete a jugar al tenis’) 

END. 

La segunda solución consiste en encerrar entre un BEGIN y 
un END la segunda IF: 

IF trabajo THEN 
BEEIN 

IF lluvia THEN 

HRITELN ('al trabajo en coche’) 

END; 

ELSE 

IF LLUVIA THEN 
HRITELN (’quédate en casa’) 
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ELSE 

NRITELN (’vete a jugar al tenis’) 

END. 

De esta manera se “convence’ 1 al compilador para que asocie 
la primera ELSE a la primera IF. 

Finalmente, supongamos que a alguien se le ocurra arreglar¬ 
lo poniendo un después de WRITELN ('al trabajo en coche')., 
esto es lo peor que se podría hacer: el_ compilador se enfadaría 
porque no le saldrían las cuentas de laslF y de las ELSE. 

Según dicen los críticos del Pascal, estos contratiempos se de¬ 
rivan de la ausencia de terminadores ENDIF. Existe una solución 
posible, aunque no muy limpia, que consiste en cerrar cada IF tipo 
abreviada con un ELSE (en efecto, si ELSE no está seguida de nin¬ 
guna instrucción, el compilador no se escfvpdaliza). En nuestro 
caso, el truco consiste en quitar el BEGIN y sustituir su END por 
ELSE. 

Finalmente, a propósito de BEGIN y END, hay que recordar 
que si deseamos ejecutar varias instrucciones a continuación de 
un IF o de un ELSE, no se podrán olvidar, en absoluto. En efecto, 
aquí no tenemos lo que normalmente ocurre en BASIC, donde si 
en una línea se tiene 

100 IF <CQNDIC> THEN instr1:instr2:instr3¡... 

todas las instrucciones de la línea se ejecutan o se saltan. 

El Pascal es más riguroso, y si nos olvidamos BEGIN y END 
asume que sólo debe ejecutar la primera instrucción. 


La estructura CASE 

El Pascal proporciona la estructura CASE para simplificar y 
aclarar las situaciones de elecciones múltiples. Es una construc¬ 
ción comodísima, siempre que a cada elección corresponda una 
sola instrucción. De todas formas, también se puede aplicar en 
otras situaciones, bien definiendo aparte procedimientos adecua¬ 
dos, o bien recurriendo al habitual dúo BEGIN-END. 

El ejemplo que veremos con la tortuga sirve para moverla en 
la pantalla pulsando algunas teclas. Las posibilidades previstas 
son: movimientos hacia delante o hacia atrás de 2 pasos de longi¬ 
tud y rotaciones absolutas según la rosa de los vientos, o sea, 
8 ángulos que van de 45 en 45 grados. Es evidente que si aquí 
no hubiera habido estructura CASE habría sido necesario inven¬ 
tarla o bien recurrir a una tabla, pero ésta sería una solución de 



menor claridad semántica. Para las dos primeras acciones adop¬ 
tamos las teclas A y S, y para las otras, las teclas que generalmen¬ 
te están dispuestas a lo largo de las 8 direcciones indicadas. Ten¬ 
dremos: 

PROBRAM tortpaseo; 

VAR caract:CHAR; 

BEGIN (t saín I) 

PENC0L0R(WHITE); 

READ(caract); 

NHILE caract<>CKR(13) DD 
(I si no es return *) 

BE6IN 

CASE caract 0F 
’ A’:NOVE (2) ¡ 

’S’:H0VE(-2); 

'J’:TURNTO(0); 

’ II’ : TURNTO (-45); 

’N’:TURNTO(-90); 

'B':TURNTO(-135); 

’H’:TURNTO(1B0); 

’Y’:TURNTO!135)} 

’U’:TURNTO(90); 

'I’:TURNTO(45>; 

END;(t final CASE I) 

READ(caract); 

END;(t final de WHILE I) 

END. * 

CASE es un ejemplo tan elocuente que no merece ningún co¬ 
mentario. Confirmar sólo que la construcción es del tipo: 

CASE (expresión) OF (lista de casos) END 

donde la lista de casos corresponde a los posibles resultados de 
la expresión. Es interesante la posibilidad de reagrupar juntos, se¬ 
parados por comas, casos que prevén una solución idéntica. En 
él programa precedente, por ejemplo, se podrían equiparar ma¬ 
yúsculas y minúsculas: 

CASE caract 0F 
’A’,’a’:M0VE(2)¡ 
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En el Pascal estándar falta la opción ELSE, asociada directa¬ 
mente a la CASE, que permita incluir, en una única acción, los ca¬ 
sos no incluidos en la lista, incluso anidándolo todo. No se nota mu¬ 
cho su ausencia, pues generalmente se suele sustituir por una 
IF/ELSE por encima de la CASE. 

Para quien nos siga con la debida atención, hacemos la si¬ 
guiente pregunta: ¿qué ocurre si, en el programa precedente, se 
pulsa una letra que no está comprendida en la lista CASE? 

Dejamos en el aire la facilfsma respuesta, que confirmaremos 
al acabar el capítulo. 


El problemático GOTO 

Terminamos la relación de las estructuras de control con el 
discutido GOTO, eliminado ignominiosamente por los estructura- 
listas a ultranza, a pesar de que realmente el GOTO no es una es¬ 
tructura, sino un constructor de estructuras. Wirth fue benevolen¬ 
te, y sólo relegó el GOTO a ciudadano de segunda, de forma que 
todos los manuales de Pascal, siguiendo su ejemplo, lo tratan al 
final y "con prisas 1 ’. 

El GOTO se utiliza en casos extremos y complicados; por 
ejemplo, donde las estructuras disponibles vuelven excesivas la 
duplicación de códigos o el abuso de booleanas. Para hacer de¬ 
sistir del uso del GOTO, Wirth pensó en introducir el empleo, un 
poco molesto, de etiquetas (label) de destino; se componen sólo 
de cifras, pero son tipos y NO manipuladles de ninguna forma y 
tienen que ser declaradas las primeras en el módulo al que per¬ 
tenezcan. Lo explicamos con un ejemplo: 

PRQ6RAM p; 

LABEL 1; 

PROCEDURE A; 

LABEL 2; 


BEGIN 


GOTO 2 


GOTO 1 


2:WRITELN('pequeño error....’) 
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END¡<! procedure a I) 


1:HRITELN 1’¡error trágico!’) 


END. 


GOTO, obviamente, es asociable a IF, obteniéndose la familiar 
combinación: IF <condic> THEN GOTO... 

En el pequeño ejemplo anterior, GOTO es útil para la salida 
anticipada de un bucle, especialmente (pero no sólo) cuando haya 
un error. Por lo tanto, aquí también es válido el principio de que 
el salto de un bloque interno a otro externo es lícito, pero no lo 
contrario. 

De todas formas, una vez que se plantea un programa con 
construcciones WHILE, REPEAT, etc., que originan módulos quizá 
complejos pero bien engarzados unos en otros y con un único 
punto de entrada y salida, GOTO, además de superfluo, puede re¬ 
sultar complicado para su manejo. Si a esto añadimos efectos co¬ 
laterales, sobre los que no podemos detenernos, pero que acon¬ 
sejan mucha precaución, es posible que tengamos que decirle 
adiós al GOTO. 

Acabamos este largo capítulo con dos asuntos. Ante todo, la 
respuesta a la pregunta sobre CASE: evidentemente, si se pulsa 
una tecla no prevista (y distinta del retorno del carro) la tortuga 
no se mueve. . . 

El segundo asunto es la presentación de las cartas sintácticas 
de las figuras 5 y 6. La figura 5 contiene todas las construcciones 
del Pascal, mientras que la 6 resume la estructura de un "bloque" 
de programa. Recordamos nuevamente que la sucesión debe de 
respetar el orden Etiqueta, Construcción, Type, Var, Procedimien¬ 
to y Function, que como truco nemotécnico, equivaldría a: "Esta 
Casa Tiene Varias Puertas Falsas”. 
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Figura 5.—Sintaxis de las estructuras de un programa Pascal. Para 
más detalles, le sugerimos consultar con manuales especializados. 
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<bloque> 



Figura 6 —Sintaxis de la estructura de un bloque de programa en 
Pascal. 
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FUNCIONES, PROCEDIMIENTOS Y LOS EXTRAÑOS 
ANILLOS DE LA RECURSIVIDAD 


Seamos serios... 

ntes de afrontar el complejo tema de los tipos 
de datos que, según lo que ya hemos visto en 
los dos capítulos introductorios están bastante li¬ 
gados a los algoritmos, nos proponemos ampliar 
nuestros conocimentos sobre las FUNCTION y 
acercarnos al mundo de la recursividad. Vea¬ 
mos, pues, un par de ejemplos relativos a las 
FUNCTION. El primero tiene un cierto carácter 
práctico. Se refiere al cálculo mensual del IRPF 
correspondiente a la base imponible de un asalariado, es decir, a 
la parte del salario bruto que queda después de haber desconta¬ 
do todos los pagos a la Seguridad Social. , 

Nótese que el algoritmo se basa sobre unas tablas aproxima¬ 
das, que no coincidirán seguramente con las que usted deberá 
emplear al liquidar su Declaración de la Renta de 1985. Paciencia, 
pues se trata simplemente de un ejercicio. El criterio de impues¬ 
tos progresivos prevé distintos tramos impositivos: 



Tramo impositivo 

Hasta 25000 
33333 
41666 
49999 
62500 
75000 


Tabla de retención 

10 % 

13% 

16% 

19% 

22 % 

25% 
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La columna de la derecha expresa el porcentaje que se apli¬ 
ca a la base imponible comprendida entre el valor de la izquier¬ 
da y el siguiente. El procedimiento que vamos a ver se basa en 
la observación de que ambas columnas tienen valores que se su¬ 
ceden con regularidad: los porcentajes de la tabla crecen un 3%, 
mientras que los tramos impositivos crecen a razón de 8.333 hasta 
49.999, y desde aquí se incrementan en 12.500 pesetas (lo extraño 
de estos números se debe a que se trata de valores anuales re¬ 
feridos a meses). 

El algoritmo que sugerimos aquí consiste en lo siguiente: 

• aplique un 10% sobre la base imponible; 

• considére un posterior 3% sobre la diferencia entre ésta y 
cada tramo impositivo, hasta que lleguemos al que corres¬ 
ponde a la base imponible. 


Realizadas estas hipótesis, escribir el pfograma es cosa fácil. 
Como de costumbre, animamos a los más voluntariosos a inten¬ 
tarlo. Sólo una obligación: utilizar una FUNCTION de nombre Imp- 
brut. He aquí la solución propuesta: 

PROBRAM IMPUESTOS; 

VAR SUELDO BRUT,RETENC,IMPONIB,IMP,IMPENET:INTEGER; 

FUNCTION IMPBRUT(IMPONIB:INTEGER):INTEGER; 

CONST INICTABLA=25000;INTERHED=49999; 

CREC1=8333;CREC2=12500¡ 

VAR TRAMIMP,IMP: INTEBER 
BEGIN 
IMP:=0; 

TRAMIMP:=IN1CTABLA;IMPBRUT:=IMP0NIB DIV 10; 

HHILE IMPONIB>TRAHINP DO 
BEGIN 

IMPBRUT : =IMPBRUT+TRUNCt<IMP0N1B-TRAMIMP) <0.03); 

IF TRAMIMP<INTERMED 

THEN TRAMIMP:=TRANIMP+CREC1 
ELSE TRAMIMP:=TRAMIMP+CREC2 
END (i WHILE t) IMPBRUT:=IMP 
END; U IMPBRUT I) 

BEGIN (t MAIN *) 

READLN (SUELDOBRUT,_); 


IMP:=SUELD0BRUT-RETENC; 
IMP:=IMPBRUT(IMP); 

END. 


Obviamente, los "puntitos" corresponden a "omisiones" que 
cada uno puede rellenar para su uso particular. 

En este ejemplo, al haber sido más concretos, se hacen evi¬ 
dentes, precisamente por esto, ciertas ventajas aparentemente for¬ 
males del Pascal. Es útil, aunque no indispensable, definir varia¬ 
bles locales de FUNCTION en cuanto sirven exclusivamente para 
el uso interno del cálculo fiscal. De esta forma se evita cualquier 
riesgo de que en el main se modifiquen variables que NO deben 
de ser influidas. Este aspecto es decisivo en la utilización recur¬ 
siva de procedimientos y funciones que vamos a ver ahora, y en 
el caso de módulos de "librería" reutilizables, como en el len¬ 
guaje Modula 2. También las constantes inictabla, intermed, crecí 
y crec2 permiten una cómoda actualización en el caso de que de¬ 
ban modificarse posteriormente (por ejemplo, para reutilizar la 
FUNCTION en el cálculo del IRPF anual en vez de mensual); es 
suficiente cambiar sólo la sección CONST del módulo en lugar de 
todas las fórmulas afectadas por el cambio (que pueden ser mu¬ 
chas en el caso de programas importantes). Se confirma así la ma¬ 
yor transparencia de un listado Pascal con respecto a uno en BA¬ 
SIC. Aunque no tenemos reparos en admitir nuestra afición por el 
popular BASIC y en apreciar sus dotes de inmediatez y sencillez, 
sin embargo tenemos que proclamar que el Pascal, aunque a me¬ 
nudo necesita mayor cuidado y tiempo para ser definido y pues¬ 
to a punto, ofrece al final unos resultados autodocumentadps, ha¬ 
ciendo innecesarios gran parte de los comentarios o diagramas 
de flujo explicativos. 

Habrá notado en el ejemplo la adopción de variables tipo 
INTEGER. Esto se debe a que en España la moneda no emplea de¬ 
cimales y, además, a que los números de 6-7 cifras que hemos uti¬ 
lizado, expresados en tipo REAL, darían lugar a resultados en for¬ 
ma exponencial, del tipo 1.0000E 6 (en realidad, el tipo INTEGER tie¬ 
ne un rango en el UCSD que se limita, aproximadamente, a 32.000, 
valor a partir del cual sería necesario adoptar el tipo LONG). En 
este momento se tropieza con la rigidez del Pascal en materia de 
tipos: generalmente está prohibido mezclar "manzanas con peras”; 
sólo se permite juntar reales y enteros, con prioridad siempre para 
los primeros. Además, si el primer miembro es de tipo entero y 
el segundo tiene algún término real se produce un error, es decir, 
no se realiza la transformación automática a tipo INTEGER. Por 
suerte, el Pascal proporciona la función TRUNC (que ya hemos uti- 
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lizado en la fórmula para obtener el total de impbrut). Además de 
la DIV, ya vista, podemos usar la operación MOD, que proporcio¬ 
na el resto de la división entre enteros (ejresto := dividendo MOD 
divisor). 

Queremos aprovechar para aclarar que entre los objetivos de 
este libro introductorio no se encuentran temas como: 

• cálculo numérico, 

O elaboración de las E/S en general; 
o tratamiento de archivos. *s. 

Para estos puntos, o para ampliar detalles sobre los vistos, le 
recomendamos la lectura de manuales más especializados. 

Volviendo al ejemplo, hacemos notar que también se podrían 
haber insertado instrucciones como: 

1MPNET:=IHPBRUT(IMP)-DESBR; 

WRITELN (’EL IMPUESTO NETO RESULTA IGUAL A: \INFSRUT(IMP)-DES6R>¡ 


Recurrir a ¡a recursividad 

Todo lo dicho puede ayudar a reconsiderar la diferencia en¬ 
tre FUNCTION y PROCEDURE. Dejamos como tarea para los más 
voluntariosos la implementación del mismo programa preceden¬ 
te por medio de una PROCEDURE que, naturalmente, contenga un 
parámetro-variable oportuno, algo así como: 

PROCEDURE IRPFIVAR IMPBRUT: INTEGER,INPONIB:INTEGER); 

Nos queda por comentar una última diferencia entre los dos 
módulos pascalianos fundamentales: el tratamiento de la recursi¬ 
vidad. Dado que es uno de los argumentos más fascinantes, y en 
cierto modo misteriosos, de lenguajes evolucionados como el Pas¬ 
cal, merece la pena que le hagamos un hueco en este libro. En la 
eterna disputa entre BASICalistas y Pascalistas, los segundos, a las 
denigraciones de los primeros ("¿Dónde están las cadenas?, ¿dón¬ 
de los archivos aleatorios?, ¿dónde...?”) reaccionan sistemática¬ 
mente encogiéndose de hombros y aludiendo con dignidad a este 
potente y extraño instrumento. 

Para empezar a presentarlo hay que comentar su estrecha re¬ 
lación con los discursos sobre discursos. Ejemplo trágico: dijo Epa- 
minonda el Cretense: "lo que estoy diciendo es falso' 1 . Ejemplo hu¬ 
morístico: "Había una vez un Rey que dijo a su criada: «¡Cuéntame 
un cuento!», y ella empezó: «Había una vez un Rey que dijo a su 



criada: «¡Cuéntame un cuento!», y ella empezó: «Había una vez un 
Rey...»" 

La serie de comillas que cierran el segundo caso hay que su¬ 
ponerla infinita, en tanto que este cuento, formado por una cadena 
de reyes que mandan hablar a criadas que hablan de reyes que 
mandan hablar a criadas que hablan de..„ evidentemente no aca¬ 
ba NUNCA. En cuanto al primer caso, los lectores más estudiosos, 
esos que, quizá esporádicamente, lean "Investigación y Ciencia" 
(de “Scientific American”) saben ya que da lugar a la famosa con¬ 
tradicción, en base a la cual el ambiguo Epaminonda si dice lo ver¬ 
dadero dice también lo falso, y viceversa. Pero dejemos de diva¬ 
gar y volvamos al Pascal. 

Dicho con palabras, la recursividad, en informática, consiste 
en que un procedimiento dado puede, desde su interior, llamarse 
a sí mismo. El juego, como se intuye, podría durar hasta el infinito, 
pero se insertan criterios adecuados siempre internos de finaliza¬ 
ción o bien una condición de final que se integra más o menos 
implícitamente en la definición. 

En vista de que dicen que la tortuga se ha creado precisa¬ 
mente para demostrar lo fácil que es comprender, incluso para 
los niños, asuntos como la recursividad, empezaremos con un 
ejemplo geométrico clásico con la tortuga: 

PR06RAM CUADRADOS; 

PROCEDURE CUADRO(LADO,INC,ALFA:INTEGER); 

VARI¡INTEGER; 

IF LADD<=200 DO 

BEGIN 

TURN(ALFA)¡ 

FOR 1=1 TO 4 DO 
BEGIN 

MOVE(LADO);TURN(90) 

END; 

CUADRO (LADO+INC,INC,ALFA) 

END; 

BEGIN (t MAIN t) 

HOVETOl120,100);PENC0LQR(HHITE); 

CUADRO < 5,2,6) 

END. 

Después de lo dicho, el resultado del programa no será ni im¬ 
previsible ni chocante: partiendo del centro de la pantalla, y de¬ 
bido a la primera llamada a Cuadro por parte del main, se traza 
un cuadrado de 5 unidades de lado y con una desviación de 
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16 grados, terminado lo cual la cosa se repite porque el Cuadro 
se evoca a sí mismo, pero esta vez con un parámetro "lado" incre¬ 
mentado en 2. Según esto, ¿hasta dónde podríamos llegar? Teóri¬ 
camente hasta el infinito, con cuadrados cada vez mayores, si no 
fuese por el providencial IF, que bloquea el proceso cuando el 
lado es mayor que 200. 

Cambiando los parámetros podemos ver lós distintos efectos 
que provocan siguiendo la peligrosa costumbre de quienes se po¬ 
nen a jugar con la tortuga. Por ejemplo, sugerimos desplazar la ins¬ 
trucción Cuadro (lado + inc, inc, alfa) aütoinvocadora antes del 
END que la precede, de forma que ahora la autollamada ocurra 
después de cada MOVE (lado) y TURN (90): 

FDR 1=1 TD 4 DD 
BE6IN 

HDVE(LADO);TURN(90> 

CUADRO(LñDO+INC,INC,ALFA) , 

END (* BUCLE FOR ») 

END; 

De este pequeño ejemplo podemos extraer dos conclusiones: 

• eh algunos casos la recursividad produce efectos que se 
obtienen más fácilmente con una simple iteración; 

• por tanto, es mejor usar esta técnica sofisticada sólo en ca¬ 
sos especiales. 

En consecuencia, antes de continuar desarrollándola sin ton 
ni son, vamos a intentar profundizar en este argumento. 

FUNCTIONS y PROCEDURES recursivas 

Conviene hacer en seguida una pequeña prueba para satis¬ 
facer una duda que seguramente ha surgido en muchos de uste¬ 
des. Eliminen en el ejemplo precedente (en su forma inicial) el IF, 
sin olvidar los respectivos BEGIN... END y anulando incluso la ex¬ 
pansión del cuadrado (haciendo en el main: Cuadro (20,0,6)). ¿De 
verdad durará hasta el infinito el trazado de estos 360/6 = 60 cua¬ 
drados? La respuesta es negativa: después de un cierto tiempo el 
sistema producirá un mensaje de “stack overfiow" (superación de 
la capacidad de la pila) y se parará. Efectivamente, esto puede 
ayudar a entender mejor lo que estamos a punto de decir: el me¬ 
canismo de la recursividad acumula en una pila (“stack") los pa¬ 
rámetros y variables locales pendientes de resolución. Ahora bien, 


toda pila dispone de un área finita de la memoria y (a menos que 
se pongan en juego mecanismos aún más sofisticados...) ésta, an¬ 
tes o después, se saturará, llegando a desbordarse ("overflow"). 

Veamos un caso sencillísimo: el de un sumatorio, desde T 
hasta "n", a cuyo total llamaremos Tot(n). La definición, también en 
matemáticas, se puede dar así: 

TOT(N)=1 SI N=1 ,EN CASO CONTRARIO 
T0T(N)=T0T(N-1)+N 

Así, por ejemplo, si n = 6 tendremos Tot(6) = Tot(5) + 6. ¿No 
es banal? Ciertamente, pero la sutileza está en reconocer que esta 
definición ES RECURSIVA POR SI MISMA, en cuanto que nos obli¬ 
ga implícitamente a volver a un cálculo, aunque sea en potencia 
y no de facto. Generalmente se prefiere la forma directa, calculan¬ 
do primero Tot(l), después Tot(2) = Tot (1) + 2, etc. La esencia del 
programa es obvia: 


T0T:=1; 

FORI:=1 TO N DO 
T0T:=T0T+I 

Pero, ¿por qué no obligar al ordenador a hacer cuentas defi¬ 
nidas recursivamente? En Pascal lo hacemos en seguida: 

PROGRAH SUMAREC; 

VAR N,I,TOTAL:INTEGER; 

FUNCTION TOT(NUMERO:INTEGER):INTEGER; 

BEGIN t 

IF NUHERQ=1 THEN T0T:=! 

ELSE TOT:=TDT(NUMERO-1)+NUNER0; 

END; 

BEGIN <» MAIN *) 

REPEAT 

READLN(N);I:=N; 

IF N<=4000 THEN 
BEGIN 

TOTAL:=T0T(N); 

NRITELN;(I RETORNO DE CARRO *) 

NRITELN (’SUMATORIO HASTA \N,’ =’,TOTAL>¡ 

END 

UNTIL N>4000 
END. 












La clave de este asunto reside en el hecho de que cuando en 
el segundo miembro de una expresión se encuentra un término 
que incluye el nombre de una FUNCTION pascaliana se realiza 
una llamada a dicha función. Esto ya lo habíamos visto a propósi¬ 
to de un WRITELN (y lo volveremos a ver); ahora nos lo encon¬ 
tramos en una expresión interna a la FUNCTION misma, con lo 
cual supone una recursividad. El juego recursivo consiste en que 
la autoevocación se realiza cada vez con valor distinto (una uni¬ 
dad menor) del parámetro "número". La condición de final del pro¬ 
ceso se cumple cuando el valor "número I" de llamada es 1. Quien 
"se fíe" del hecho de que el Pascal sostiene la recursividad tiene 
que "creer" que estas cosas suceden, y por otro lado, la prueba 
empírica se puede obtener simplemente haciendo correr el pro¬ 
grama y proporcionándole diferentes valores de "n". A propósito: 
habrá notado una variante del usual WHILE mediante REPEAT que, 
por esta vez, permite utilizar un solo READLN. De todas formas, me¬ 
diante tanteo, podrá lograr la parada del programa por "stack over- 
flow" (superación de la capacidad de la pila) para valores altos 
de "n" (alrededor de 2000 para un ordenador personal corriente). 
Esto estimula de nuevo nuestra curiosidad sobre el tema, además 
de recordarnos que no debemos abusar de la recursividad, espe¬ 
cialmente en los pequeños ordenadores domésticos. Para intentar 
comprender por nosotros mismos este mecanismo, les invito a in¬ 
cluir una nueva línea después del ELSE de Tot: 

I:=1-1;WRITELN('RASTRO: \I); 

¿Por qué se ha adoptado una variable global? Pues porque 
no era muy sencillo hacerlo de otra forma: una variable local hu¬ 
biera sido más adecuada, pues se quiere seguir las huellas de lo 
que sucede en el sitio, pero se presentaba muy enmarañado el 
problema de la inicialización, por lo menos para un principiante. 
Si ponemos en el main el valor inicial "i" igual a "n", la instrucción 
arriba vista parece la más lógica. En la práctica, ¿qué es lo que 
sucede? He aquí la salida del programa en el caso n = 4: 

Rastro: 3 

Rastro: 2 

Rastro: 1 

Rastro: 0 

Sumatorio hasta 4 = 10 

Seguramente el 0 haya producido alguna sorpresa. Veamos 
qué ocurre si modificamos la nueva línea de esta manera: 

I:=1-1 iWRITELM(’RASTRO: '.NUMERO,’ ’,1); 


El resultado de la ejecución sería: 


Rastro: 1 3 
Rastro: 2 2 
Rastro: 3 1 
Rastro: 4 0 

Sumatoria hasta 4= 10 


Esperamos no haber causado ningún ataque cardíaco. Aun¬ 
que en principio resulte increíble, la asociación de valores para 
"número" e "i" es correcta. En efecto, la recursividad deja pendien¬ 
te la realización de todos los cálculos que no pueden ser ejecu¬ 
tados (cada vez que el parámetro "número" decrece), pero con¬ 
serva los valores con los que habrá de hacerlos en la pila. Así, 
cuando llegamos a la presencia de la condición IF, con número = 1 
tendríamos problemas si no se hubiesen conservado uno a uno to¬ 
dos los valores precedentes de "número" con los cuales hay que 
trabajar ahora. Cuando son precisos se repescan en orden inverso. 
al que han sido "apilados" en la pila usada por el Pascal. En el caso 
de ’n = 4 poco a poco tendremos que añadir a Tot:=l, 2, luego3 y 
4, en este orden. 

Los que aún no están del todo convencidos preguntarán: ¿por 
qué entonces los valores de "i" van desde 3 a 0? Esto depende 
del hecho de que "i" es una variable global y, por lo tanto, NO 
está almacenada en la pila. Sin embargo, la ejecución de la ins¬ 
trucción i:=i-l y los sucesivos WRITELN han quedado en reserva 
por las llamadas "de telescopio" del Tot (número-1) y sólo cuandoo 
número=l empezará a decrecer i: ésta es la explicación c}e por¬ 
qué "i” va desde 3 a 0, decrementándose 4 veces antes de volver 
definitivamente al main. 

En la figura 1 se representan, en cuatro planos distintos, las su¬ 
cesivas variaciones de la pila, con la operación evocada (y en re¬ 
serva) y los parámetros apilados. Desde un punto de vista gene¬ 
ral todo lo que es "local" —es decir, variables y parámetros se 
reserva en la pila es por esto por lo que, en problemas en los que 
están en juego un mayor número de parámetros, la pila se "de¬ 
rrumba" antes. . . 

Las flechas que apuntan hacia arriba, a la izquierda, simboli¬ 
zan las 4 operaciones sucesivas de PUSH (empujar literalmente), 
mientras que a la derecha se representan palabras condicionales 
como IF o ELSE. La presencia de IF en la cima (último plano) da 
lugar a un desbloqueo de la situación (que en otro caso llegaría- 
ai infinito o, en realidad, al desbordamiento de la pila). Entonces 
se activa el mecanismo de cálculo hacia atrás, con los 4 POP (ex- 
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Tot{1) = 1 


número=1 


Condición Resultados 

"desencadenante" sucesivos 

Tot. 


1 CD 

J Toi(2)=T ot(1)+2 número=2 
\ 1 

I Tol(3)=Tot(2)+3 número=3 

C. .J 


'**•//Plano del main }// 


{EISE} 
& 


1+2 = 3 


3+3=6■ 


[ Tot(4)=Tot(3)+4 

número=4 


J 



1 

(ELSE) 

6 + 4=10 

PUSH 

( n = 4 



) 



M Figura ¡.—La figura trata de evidenciar el funcionamiento de ¡a pila 
interna (stack) guardando parámetros y variables locales y mante¬ 
niendo en reserva fórmulas cuando se invoca una recursiva, como en el 
programa del sumatorio. „ 


traer, lo contrario de Push), necesarios para volver al main, con la 
consiguiente recuperación de los distintos valores. 

Por último, veamos otra posible variante, adoptando un 
PROCEDIMIENTO (naturalmente con un parámetro-variable). 
Aunque es evidente que para un caso analítico es preferible una 
FUNCTION, proponemos esto como un útil ejercicio explicatorio. 
Nuestra solución es ésta: 

PROBRAM SUhAREC; 

VAR N,SUMA:INTE6ER; 

PRDCEDURE TOTALtVAR TDT:INTEGER;NUMERO:INTE6ER); 

BE6IN 

1F NUMER0=1 THEN T0T:=1 
ELSE 
BEE1N 

TOTAL(TDT,NUMERD-1);TOT:=TDT+NUHERQ; 

END; 

HRITELN ('RASTRO: ’.TOT,' NUMERO) 

END; 

BEEIN (I MAIN *) 



IF N<2000 THEN 
BEGIN 

TOTAL(SUMA,N);HRITELN (SUMA) 

END 

UNTIL... 

END. 

Ahora los comentarios casi sobran. La distinta estructura nos 
ha hecho introducir una nueva variable global 'suma' para hacerla 
pasar como parámetro "de referencia" al procedimiento Total. Así 
podemos subrayar por fin la última diferencia entre FUNCTION y 
PROCEDURE: en las operaciones de cálculo, la primera está, por 
así decirlo, mejor dispuesta para la recursividad, mientras que la 
segunda debe llamarse explícitamente y debe ser seguida por la 
instrucción que maneja el parámetro-VAR; el mecanismo también 
está garantizado, pero al estar la segunda operación en reserva 
por la evocación de Total, automáticamente queda guardada en 
la pila habitual (una pregunta: ¿qué habría sucedido si nos hubié¬ 
ramos olvidado de encerrar las dos operaciones entre BEGIN y 
END...? , 

Quizá exista la pequeña ventaja de la mayor comodidad con 
la que se puede tener ahora un rastro de los cálculos "hacia atrás" 
(aquí conviene hacer otra pregunta: ¿cuál es el mejor lugar para 
situar la instrucción siguiente: 

WRITELN ('Rastro; 'tot, "número);?Hay que razonarla antes de pro¬ 
barla en el ordenador personal. 


Arboles y dragones 

Esta larga y prolija charla sobre temas elementales tenía fines 
únicamente pedagógicos, pues, como muchos de ustedes saben, 
el sumatorio de los enteros de "1" a “n" viene dado directamente 
por la fórmula. 

S(n) = n*(n + 1 )/2 
Ejemplo: S(4) = 4*5/2= 10 

Como ya hemos aprendido muchas útiles sutilezas podemos 
pasar a desarrollar bastante velozmente ejemplos más complejos. 
Aunque nos limitaremos a casos gráficos de la tortuga, pueden es¬ 
tar seguros de que la recursividad encuentra aplicaciones muy se¬ 
rias, sean o no numéricas, en los más diversos campos, teniendo 
como terreno privilegiado el de la llamada Inteligencia Artificial, 
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permitiendo mecanismos de búsqueda en árboles (decisiones, 
movimientos estratégicos y similares) que, en caso contrario, se¬ 
rían extremadamente incómodos, por no decir imposibles de rea¬ 
lizar en forma iterativa, Generalmente, y a grandes rasgos, se pue¬ 
de afirmar que la recursividad es cara en términos de memoria 
(por la gran cantidad de memoria que necesita para la pila) y de 
velocidad de ejecución (por culpa de los PUSH y POP, aunque 
esto puede variar de un problema a otro), pero tiene a su favor la 
ventaja de su potencia expresiva, además de computacional, y su 
carácter sintético. *•'- 

Pasemos ahora al examen de otro caso interesante, muy cita¬ 
do también en los manuales de Logo. 

PROGRAN CURVASDELDRABON; 

USES TURTTLE6RAPHICS; 

VAR NIV:INTEGER; 

PROCEDURE DRA60N(NIVEL,LAD0¡INTEGER); 

BEGIN 

IF NIVEL=NIV THEN 

NOVE(LADO) 

ELSE « 

BEGIN 

TURNI45); 

DRAGON(NIVEL+1,ROUND(0.707ILADO)); 

TURN1-90) 

DRAGON(NIVEL+1,ROUND(0.707ILADD)); » 

TURNI45) 

END;(* ELSE t) 

END; 

BEGIN (t NAIN I) 

INITTURTLE 
FORNIV:=0 T0 B DO 
BEGIN 

PENCOLOR(NQNE);MOVET0(70,5O); 

PENC0L0R(MHITE);DRAGON(1,140); 

READLN 

END (I FDR ») 

END. 

Se han puesto a propósito las instrucciones para hacer fun¬ 
cionar el programa concretamente con el Pascal del Apple, con 
el fin de permitir al menos a los poseedores de este ordenador 
realizar un experimento, lo que siempre ayuda a comprender el 
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mecanismo. En efecto, las 8 veces que se realiza el ciclo FOR del 
main se trazan otros tantos fragmentos recursivos de la curva, in¬ 
terrumpidos por la instrucción READLN, así que apretando Return 
se les puede ver perseguirse uno a uno. Si, en cambio, quiere ver 
dibujado todo a la vez, basta con suprimir READLN. 

Examinando ahora la definición del procedimiento Dragón se 
ve inmediatamente que se compone de tres fases: un giro de 45 
grados más la ejecución de Dragón, un giro de 90 grados en el 
sentido de las agujas del reloj, y luego, de nuevo, el Dragón se¬ 
guido de una rotación de 45. 

En ambos casos hay auto-evocación, con reducción del pará¬ 
metro lado (pasado inicialmente con un valor de 140 desde el' 
main) mientras que el parámetro nivel es incrementado en una 
unidad. 

En base a lo que hemos dicho hasta ahora no es demasiado 
difícil darse cuenta de lo que ocurre después de los dos primeros 
pasos del bucle FOR, o sea, cuando la variable global "niv" tiene 
valores 0 y 1, En el primero se verifica la condición nivel=niv, lue¬ 
go ELSE ni siquiera se toma en cuenta y se traza un segmento ho¬ 
rizontal de lado 140, devolviendo el control al main. Cuando niv, 
en el segundo paso, vale 1, se verifica la condición que activa 
ELSE, puesto que ahora nivel=0 y niv=l. Por lo tanto, se conecta 
el mecanismo de recursividad con un "lado” 0.707 veces (redon¬ 
deado en el interior con la función ROUND) el valor que le ha sido 
pasado por el main. Con la segunda auto-evocación se completa 
la triple fase descrita más arriba. Para todos aquellos que saben 
que 0.707 (el inverso de la raíz de 2) es el coeficiente que liga el 
lado con la diagonal del cuadrado no será difícil comprender que 
tendremos el trazado de la curva señalada con "nivel 1" en la fi¬ 
gura 2. Dos observaciones: t 

• a cada nuevo paso del FOR la pareja de instrucciones PEN- 
COLOR (NONE) y MOVETO (70,50) vuelve a poner a la tor¬ 
tuga en el mismo punto de salida; 

• como es evidente en la figura 2 la tortuga acaba su viaje 
con un ángulo relativo final cero (+45 -90 +45). 

Si llamamos "diente de dragón" a este triángulo rectángulo (la 
punta del diente forma un ángulo de 90), comprender los movi¬ 
mientos sucesivos significa darse cuenta de que las cosas van de 
tal foma que se traza un diente de dragón sobre cada uno de los 
lados que competen al nivel inmediatamente precedente. 

Nos falta espacio para un análisis más detallado y por eso les 
remito al ejemplo anterior. Aquí nos limitaremos a hacer una ob¬ 
servación importante, sin la cual cualquiera se puede despistar fá¬ 
cilmente. Las llamadas recursivas a Dragón (nivel+1, ROUND (0.707 

95 



Sentido de movimiento 
de la "tortuga" 


M Figura 2.—Recorridos de la tortuga en el programa CurvasdelDra- 
gón en los valores 0, 1 y 2 de nivel. En el caso del nivel 1 se ponen 
en evidencia ¡as rotaciones relativas de la tortuga. El ángulo final resultan¬ 
te es nulo. 


* lado)) son dos; por lo tanto, nos preguntamos: cuando la primera 
permanece en reserva, ¿hay que seguir repitiéndola hasta llegar 
a nivel=niv o hay que pasar a examinar la segunda llamada a Dra¬ 
gón? La respuesta correcta es la primera, como puede compro¬ 
bar si tiene la paciencia suficiente con la pila, aunque basta con 
"convencerse" de que el compilador ve como un todo aquello que 
hay entre el BEG1N y el END del ELSE, dejando, por así decirlo, 
en reserva el cuadro ejecutivo entero. 

Concluyendo, en el nivel 2, por ejemplo, tendríamos la si¬ 
guiente sucesión de hechos: giro de 45 (nivel 1 en reserva): giro 
45 (niv 2), verificación de IF y consiguiente ejecución del primero 
de los 4 lados; giro de -90 (niv 2), segundo lado (debido al segun¬ 
do Dragón que también está en reserva), y giro de 45 (con lo que 
la tortuga ahora está paralela al primer lado del niv 1); sigue un 
giro de 90 (¡ahora nivel 1!), etc. 

Una última observación: las varias instrucciones TURN, que no 
son procedimientos recursivos, aunque estén en reserva (podría¬ 
mos decir que por culpa de otros), al final son atendidas por igual, 
mientras que MOVE (lado), condicionada por IF, es ejecutada 
solamente en el último nivel. Si alguien no se ha convencido de 
esto, puede intentar hacer seguir READLN por una instrucción 
INITTURTLE (CLEARSCREEN en otros sistemas) o incluso puede 
probar a eliminar el FOR con una única instrucción de asignación 
tipo niv:=6, se dará cuenta de que sólo se dibuja una curva. 



Otras indicaciones 

La figura 3 ilustra el dibujo que se obtiene haciendo correr el 
programa precedente hasta el nivel 5. Por encimaseobienen 
efectos imprecisos debidos a la aproximación de la función 
ROUND (y,en definitiva, a la baja resolución gráfica). Se pueden 
obtener variantes de diferentes maneras, por ejemplo, cambiando 
el diente del dragón, introduciendo elementos pseudo-aleatonos 
y así sucesivamene. Otros criterios pueden ser del úpo lusúado 
por el programa de la figura 4 y su correspondiente ejecución 

(Fig.5). 



También se habla de recursividad mutua entre procedimien¬ 
tos... Nos parece oír que alguien murmura una pregunta, ¿pero to¬ 
das estas extrañas cosas, en la práctica, para qué sirven. Nueva¬ 
mente repetimos que la recursividad sirve para muchos otros 
campos, como la búsqueda de datos en es ructuras de árbol tam¬ 
bién en la base de la Inteligencia Artificial, donde el barrido con 
técnicas recursivas de árboles de decisión (por ejemplo el estu¬ 
dio de los movimientos en un juego) está a la orden del día, e in¬ 
cluso es el fundamento de lenguajes especies corno el LISP y 
el Prolog. En diferentes manuales aparece la solución recursiva 
del brillante e instructivo juego de las Torres de Hanoi, que, por 
ln tanto, nos limitamos a citar. 
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PRÜ6RAM ARBORESCENCIA; 

VAR ESCALA,ORDEN:INTEGER; 

PROCEDURE ARBOL (X,Y.LON6,DIR:INTEGER); 

PRDCEDURE CAMBIAXY; 

VAR DELTAX,DELTAY:INTEGER; 

BEGIN 

IF DIR<0 THEN DIR:=DIR+B; 

IF DIR>=8 THEN DIR:=DIR-8; 

CASE DIR OF 

0: BEGIN DELTAXi=1;DELTAY:=0;EMD; 

1: BEGIN DELTAX:=3;DELTAY:=1¡END; 

2: BEGIN DELTAX:=0;DELTAY:=1;END; 

3: BEGIN DELTAX:=-l;DELTAY:=1;END; 

4: BEGIN DELTAX:=-l;DELTAY:=0;END; 

5: BEGIN DELTAX:=-l;DELTAY:=-l;END; 

6: BEGIN DELTAX:=0;DELTAY:=-i;EMD; 

7: BEGIN DELTAX:=1;DELTAY:=-l;END; 

END; I» CASE t) 

X:=X+ESCALAILONSIDELTAX; ¿ 

Y:=Y+ESCALAILONGIDELTAY; 

END; (* CAMBIAXY I) 

BEGIN (I ARBOL t) 

PENCDLOR(NONE) 

M0VET0(X,Y);TURNT0(DIR*45); 

PENCOLOR(HHITE); 

CAMBIAXY;MOVETO(X,Y)¡ 

IF L0NG>1 THEN 
BEGIN 

ARBOL(X,Y,LONG-Í,DIR+i); 

ARBOLIX,Y,LONG-1,DIR-1) 

END: 

END;(I ARBOL *) 

BEGIN (I MAIN *) 

NRITE ('ESCALA ? ’)¡READLN (ESCALA); 

«RITE ('ORDEN ? ’);READLN (ORDEN; 

ARBOL(O,-ESCALAÍORDEN-IOO,ORDEN,2); 

END. 

Figura 4.—El programa Arborescencia ilustra eficazmente el concep¬ 
to de recursividad. 



Figura 5— Arboles de nivel 1,2 y 4 creados por el programa Arbo¬ 
rescencia, cuyo listado aparece en la figura 4. 


El asunto se sale de los objetivos de este libro, bastai con se 

ñalar qué técnicas gráfíco-recursivas están enCenador 
mados “fractales", líneas recortadas generadas por e ordenador 
que, variando pacientemente diferentes parámetrosy comb’nán 
dolas sabiamente con una pizca de aleatonedad, dan lugar a sor 
prendentesTmágenes que Avocan montañas valles paisajes uña¬ 
res fantásticos e irreales. ¡El arte computerizado es una mezcla fas 
cinante de mecánica y creatividad! 


¿Ye! BASIC? 


Nos podríamos preguntar si es del todo exacto que el BASlC 
no soporta la recursividad. Probemos a verificar el funcionamien¬ 
to de este programa: 


100 REM RECURSIVIDAD EN BASIC 
110 GOTD 500:REM INICIO MAIN 
120 REM SUBRUTINA RECURSIVA 














130 IF I=FINfiL THEN 150 

140 I=l+:PRINT "EVOCACION NUMERO ";I:EOSUB 120 

150 PRINT:PRINT "¡RECURSIVIDAD,SEÑORES! “;I 

160 RETURN 

500 REM MAIN 

510 INPUT “INDICAME EL FINAL”,FINAL 
520 GOSUB 120 
530 END 


Un basicalista distraído al que hiciéramos de pronto esta pre¬ 
góte. seguramente contestará que el programa, por ejemplo para 
FIN=5, escribe: 

EVOCACION NUMERO 1 

EVOCACION NUMERO 2 

EVOCACION NUMERO 5 

¡RECURSIVIDAD, SEÑORES! 5 

En cambio, muy sorprendido, verá aparecer el mensaie ¡RE- 
CURSIVIDAD, SEÑORES! todavía cinco veces. Lo extraño es que 
por un lado se tiene una interlínea y, además, no se imprimen los 
valores decrecientes de I desde 5 hasta 1 como quizá esperaría 
un pascaliano distraído, sino repetidamente: 

¡RECURSIVIDAD, SEÑORES! 5 

¡RECURSIVIDAD, SEÑORES! 5 

.(etc.). 

Dado que también en BASIC (e incluso en lenguaje máquina) 
las subrutinas se basan en una pila que acumula los valores de re¬ 
torno, el primer punto se explica en seguida: si las operaciones 
en reserva son las de la línea 150, también forma parte de ellas el 
primer PRINT y por eso se repite. En cuanto a la monotonía del 
valor 5 del ejemplo, se debe a que en BASIC no se tienen pará¬ 
metros y todas las variables son globales. 

Así comprendemos finalmente cómo puede ser ventajosa 
aunque pesada a veces, la distinción entre variables de diferente 
nivel que nos pareció tan pedante. 

Por último, hay que probar dando a FINAL valores cada vez 
más elevados: nos daremos cuenta de que esta recursividad dei 
BASIC es verdaderamente espartana (el mensaje de saturación de 
capacidad sale para un FINAL de 20 ó 30 y las cosas empeoran 
trágicamente con programas largos). 
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Si auiere se puede construir artesanalmente una pila en un 
proiama BASIC ,de forma que se puedan reservar todas las va- 

na ° Es postble 1 pero esmucho más cómodo tenerlo ya todo he¬ 
cho de antemano. 

Como en Pascal. 
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ESTRUCTURAS DE DATOS Y ALGORITMOS: 

TODO GUARDA RELACION 


Tipos definidos por ei usuario 



etomamos ahora el tema de la estructura de los 
datos que ya hemos visto a grandes rasgos en 
los primeros capítulos. Por cuestiones de espa¬ 
cio tendremos que esquematizar mucho este 
tema. Por otra parte, esto es un ensayo (peque¬ 
ño) y no un tratado. Para aquellos a quienes abu¬ 
rre la teoría queremos recordar que sin la abs¬ 
tracción no se pueden dar pasos adelante ni si- 
quiera en la práctica. De todas formas, además 
de hacer un rápido resumen sobre la estructura de datos del Pas¬ 
cal pondremos ejemplos ilustrativos (incluso con sus correspon¬ 
dientes programas equivalentes en BASIC). Asi trataremos dé dar 
también respuesta al angustioso (y por ahora no res ^®^ 
ma del planteamiento estructurahsta de un lenguaje pop^r que 
carece de formas estructuradas. Entiéndase bien que hablamos de 
dialectos comunes, en los cuales no hay prácticamente ni rastro 
de tipos estructurados. Aludiremos fugazmente también a nuevOo 
faSs 5go eSucturadcs, como el SUPERBASIC, lanzado por 

SmC para comodidad del lector hemos repetido en la |fj» ! j 1 

?Lto también el tipo STRING ofrecido en el UCSD Pascal por 
les (más generosoque el'"tacañc> 












Tipos de dalos 



Enteros Caracteres 


Reales Booleanos 

ÉSPascal. 1 ~ Cuadro sinó P tico de los tipoibproporcionados por el 


a los llamados tipos "escalares”. Esta denominación deriva del he¬ 
cho de que pueden asumir valores únicos que forman una espe¬ 
cie de escala de valores, en fila uno tras otro. Si lo pensamos bien 
esta granulandad" de los datos escalares no se adapta, a primera 
vista, a los números reales, que forman un dominio continuo no nu- 
merabie; pero estas sutilezas no tienen sentido en la aritmética de 

S Ón fir \ ita del calculador, donde también los números reales 
están formados por un numero máximo de cifras. 

Un amigo nuestro ha definido los tipos escalares definidos por 
S,S2E° com ° la cen icienta del Pascal”, pero su utilización P in- 
teligente permite una gran claridad en los programas y alquna 
ventaja inesperada. 7 y 

Estos tipos escalares descritos por el usuario se definían de 
do.; formas: por intervalo (como subconjunto de otro tipo exclui¬ 
dos los reales) o bien por enumeración y que, una vez definido? 
nos permiten disfrutar de: 

• las funciones estándar SUCC (x), PRED (x) y ORD (x) que 

proporcionan, respectivamente, el elemento sucesor o el 
predecesor de un dato "x”, o su número de orden 

• las relaciones >,< y =. 
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He aquí un ejemplo instructivo. Se refiere al problema del 
transbordo en una barca por un campesino de un lobo, una cabra 
y una coliflor Esta es la solución que proponemos: 

PR06RAM CABRALOBOCQLIFLQR; 

TYPE PERSDNAJES=(CAMPESINO,LOBO,CABRA,COLIFLOR); 

PASAJERO 1 (LOBO..COLIFLOR)¡ 

VAR PAS1.PAS2:PASAJERO; 


1F (0RDIPAS1))=(0RD(PAS2)+1) THEN COMILONA 


El ejemplo ilustra tanto la definición por enumeración (en el 
TYPE personajes) como la de intervalo (en el TYPE pasajero). 

El problema de este programa es que se tiene que valorar en 
un determinado momento, si existe el riesgo tíe que se active un 
procedimiento (genérico e mtuible) llamado Comüoi^ Ahotta 
bien, la condición de IF se adapta perfectamente. Tanto al lobo 
aue se come a la cabra, como a que ésta se coma la coliflor sin 
necesidad de utilizar IF anidados ni CASE: ubi maior minor editur 
(el pez grande se come al chico). 

ElüpoñRRAY 

Con este tipo, llamado a veces "vector”, ya que sólo tiene una 
dimensión, se puede hacer casi todo en BASIC (en particular se 
consigue emular estructuras como las listas y los árboies, según 
veremos seguidamente). Para ser breves y suponiendo que tra¬ 
tamos con personas que saben BASIC (si no basta JSÍÍm ¿bre 
volúmenes de la BBI) daremos por conocidas las noc ones sobre 
dimensión e indice. A este último, en Pascal se le llama también 
"selector”, va colocado entre llaves cuadradas [ ] y es modificare. 

A diferencia de los locos de la electrónica, que conciben un 
array como un conjunto de celdillas coiocadas en la memona los 
estructurales pascalianos lo ven como un tipo abstracto asimi 
lable al concepto matemático de matriz. Veamos la definición ge 
nérica de un tipo-array en Pascal: 

TYPE Reparto = ARRAY [Indi, Ind2...] OF Tipo. 

Tipo puede ser a su vez de cualquier tipo (escalar, estructu¬ 
rado, estándar o creado por nosotros) mientras que Indi, Ind2 e- . 
nen que ser escalares. Esto permite una variedad de combinacio¬ 
nes impensables en el BASIC. 
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PRQSRAM DIETARIO; 

TYPE MESES=(ENER,FEB,MARZ,ABRI,MAY,JUN,JUL, 
AGO,SEPT,OCT,NQV,DIC); 
DINERDMENS=ARRñYEHESES3 OF INTEBER; 

VAR MES:MESES;ENTRADAS,SALIDAS:DINEROMENS; 


SALIDASIDIC3:=SALIDAS[DIC]+PAGAEXTRA; 

SALDO:=0; 

FOR MES:=ENER TO DIO DO ^ 

BEGIN 

ENTRADASIMEShCNTRADASIMESl-SALIDASIMESl; 

SALDO:=SALDO+ENTRADASIMES] 

END; 

WRITELN ('BALANCE ANUAL:’.SALDO) 

Hay que reconocer que, una vez definido el ARRAY dinero- 
mens que tiene como índice al tipo-escalar mes, es bien sencillo 
manipular, con la variable mes, el ciclo FOR para calcular el hi¬ 
potético balance anual. 

Lo fundamental es que el Pascal permite para los arrays 
multidimensionales una representación más elocuente que la 
DIM X(10, 20, 10) del BASIC. 

Para hacer entender mejor la riqueza de expresión que se 
puede conseguir con el tipo ARRAY, haremos un ejemplo, pare¬ 
cido al anterior, pero suponiendo gastos y beneficios divididos en 
tres géneros: compensaciones, mercancías y servicios. 

PROGRAM DIETARIO; 

TYPE MESES=(ENER,FEB,MARI,ABRI,MAY,JUN,JUL, 

AGO,SEPT,QCT,NOV,DIC); 

GENER0S=(COMPENSACIONES,MERCANCIAS,SERVICIOS); 

DINEROMENS=ARRAYIMESES] OF INTE6ER; 

VAR MES:MESES;VOC:GENEROS;ENTRADAS,SALIDAS:DINEROMENS; 


Quien lo prefiera puede disponer también de la fórmula ha¬ 
bitual. En el caso anterior sería: 

DINEROMENS=ARRAYIMESES,GENEROS] OF INTEBER; 

Ahora, la parte de cálculo puede estar formada por dos bu¬ 
cles FOR anidados uno en el otro: el interior puede totalizar sobre 
los tres géneros. 
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SALIdÁsÍd'ic", COMPENSACIONES! :=SALIDAS[DIC,COMF'ENSACIONES]+PAGAEXTRA; 

SALDO:=0; 

FOR MES;=ENER TO DIC DO 
FOR VÓC:COMPENSACIONES TO SERVICIOS DO 

ENTRADASEMES, V0C3: =ENTRADASCMES, VOCl-SftLIDASEtlES, V0C1; 

SALDO:=SALDO+ENTRADASIMES,V0C1 
END; 

NRITELN ('BALANCE ANUAL:’,SALDO) 

VECTOR=ARRAYt100..10001 0F INTEBER 

mmm 

mwwmm 

HSSSSsf: 

“¿“SrakSÍsB darán cuenta de que esta vea ne fe- 
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PROGRAM Criba ; 

CON3 campo = ÍOOOO; 

VAR hipotprim: ARRAY (2. .campo) OF BÜOLEAN; 
primo; pr ; :incr; c uen tapr linos: INTEGER; 

PROCEDUREl todosprirnos; 

VAR ind: INTEGER; 

BEG1N 

POR ind: - 2 TO campo DQ 

BEGIN hipotprim (ind): «TRUE END 
END; («Todos primos*) 

BEGIN («Main*) 
todosprimos; 

FOR primo:=2 TO campo DIV 2 DO 
IF hipotprim(primo) TREN 
BEGIN 

incr:=primo; pr:=primo+incr ; 

REPEAT 

hipotprim(pr):=FALSE; 
pr:= pr+incr; 

UNTÍL.. prcampo; 

END; 

WRITE ('Lista primos en el campo’); 

WRI tELN ( !, de 2 a v , campo); WRITELN; 
c uentapr irnos: -O; 

FOR primo:~2 TO campo DO 
BEGIN 

IF h ipotprim(primo ) TFIEN 
BEGIN 

cuentaprimos: =c uentaprimos+1; 

WRITELN(primo); 

END; 

END; 

WRITÉLN; 

WRITE( ' Total primos: s , cuentaprirnos); 
END. 

¡SM Figura 2.—Programa que realiza el algoritmo de la criba, de Eratós- 
ñWiw tenes. La estructura de datos que mejor se le adapta es un array de 
valores booleanos, al principio todos TRUE y cambiados progresivamente 
por valores FALSE. Al acabar son números primos los índices correspon¬ 
dientes a los valores del array "hipotprim" que han permanecido en TRUE. 


mos introducido ARRAY como simple definidor de una VAR. En 
efecto, ARRAY tiene dos caras: define a una VAR de tipo array, al 
mismo tiempo que sirve también como constructor de tipo. Ge¬ 
neralmente nos convendrá definir un TYPE (estructurado), ya que 
resulta bastante complejo cuando se tienen varias VAR del mis¬ 
mo tipo. 


RECORD, SET y FILE. Los otros tipos estructurados 

El tipo RECORD ha sido considerado por Wirth como "quizá 
el más flexible de los tipos de dato". Históricamente, nació con las 
tarjetas perforadas, subdivididas en diferentes campos, cada uno 
de los cuales contiene un dato de distinta naturaleza, pero que per¬ 
mite identificar un determinado sujeto. La sintaxis en Pascal es la 
siguiente: 

TYPE <tiporecord>=RECDRD (campos) END 

Dos ejemplos típicos: 1) La tarjeta de registro que contiene 
la serie ordenada de apellidos, nombre, lugar de nacimiento, di¬ 
rección, etc., y 2) una entrada cualquiera de una tabla que asocia 
el correspondiente precio (o descuento o cualquier otra cosa que 
se quiera) al código (o nombre) del articulo. Generalmente, el 
prestigio de los lenguajes estructurados es debido al hecho de 
que proporcionan una visión abstracta que en los lenguajes tra¬ 
dicionales se solía relegar a los registros (récords) situados en so¬ 
portes externos. De todas formas, el BASIC no ofrece este tipo de 
ventajas y el programador tiene que arreglárselas con los tipos or¬ 
dinarios. 

Fijémonos, por ejemplo, en una tabla de descuentos. En 
BASIC tendríamos que apañarnos con dos arrays, digamos 
NOMART (NOMbre ARTículo) y DESC, que luego tendremos que 
hacer marchar juntos bajo nuestra personal supervisión (nada di¬ 
fícil, pero aburrido y poco operativo). En cambio en Pascal sería: 

TYPE tabladescuentos=RECQRD 

nDiaart: STR1NG; 
descuento:INTEGER 
END; 

En suma, se trata de una lista de datos, de distintos tipos, en- - 
cerrados entre las palabras reservadas RECORD y END Otro ejem¬ 
plo clásico: 
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PROGRfiM nuneroscospl; 

TYPE cDiople j=RECORD rea,imag:REAL END 
VAR x,y,z:cosplej; 

PROCEDURE sumaconpl(VAR sunaconpl;complj;a,b;conolj); 
BEGIN 

surcacoupl, r ea: =a. rea+b. rea; 
sunacoitpl ,i nag;=a.inag+b.iaag 
END; 

PROCEDURE procdcorapl(VAR procdconpliconolej;a.bicouplej)¡ 
BEGIN 

procdconpl.rea:=a.rea»b.rBa+a.ifflagtb.inag; 
procdconpl.:uag:=a.rea»b.imag+a.inaglb,rea; 

END; 


BEGIN (I nain ») 

NRITELN (’dame 2 números complejos ’); 

«RITE I’(primero la parte real,luego la imaginaria)’1; 

READLN (x.rea,x.iraag,y.rea,y.i*ag); 
sumaconpl(z,x,y)¡WRITELN; 

NRITELN (’su suma vale: ’.z.rea,’ +j ’.z.ina^; 
prodconpl(z,x,y)¡WRITELN; 

WRITELN (’su producto vale: ’.z.rea,’ +j ’.z.inag); 

. etc. 

El ejemplo "habla" por sí mismo. Es interesante señalar, sin em¬ 
bargo, que al campo de un registro (record) se accede poniendo 
el nombre del registro seguido por un punto y el nombre del cam¬ 
po. Nótese también que usamos un PROCEDIMIENTO; en efecto, 
en Pascal no se admiten FUNCTIONS que no sean de tipo escalar 
Son interesantes las combinaciones de este tipo de datos con 
otros, especialmente con el tipo array. Antes de poner un ejem¬ 
plo de esto debemos referirnos al llamado RECORD "con varian¬ 
tes". En esencia, se trata de un RECORD (registro) que contiene 
por lo menos un campo que condiciona, según sus posibles valo¬ 
res (un número prefijado y limitado) el significado de otros cam¬ 
pos. Por ejemplo: 

TYPE mes=iener.feb.narz,abril,may.jun.jul, 
ago,5ept,oct,nov,dic); 

fecha=RECQRD di a:1..31;mes:nes;annD:INTEGER END 
categart=(confec,agranel,detenorable); 
producto=RECQRD 


descrío;ARRAYE 1..20] OF CHAR; 
almac:RECORD 

codigua:INTEGER; 

noabrema:ARRAYE 1..101 OF CHAR; 

END; 

CASE catscategart OF 
pontee:(deposito:INTEGER); 
agranel:(deposito,decim:INTE6ER;um:CHAR); 
deteriorable:(deposito:INTEGER;estropeada:BOQLEAN) 

END; 

Este ejemplo debería de ser suficientemente claro (vea lo dicho 
en el capítulo 2). Nos permite apreciar cómo la estructura RECORD 
admite cómodas subdivisiones en subcampos.. En cuanto a CASE 
que aquí está aplicada a las "variantes", consiente campos de sig¬ 
nificado y estructura altenativa: en el caso específico de que el 
campo discriminador "cat” contenga "confec" irá seguido de un 
campo "depósito" de tipo entero; si, en cambio, son artículos a gra¬ 
nel, le seguirán dos campos enteros ("depósito" y "decim") y un 
tercer campo de cadena con la unidad de medida (abreviada), 
mientras que en la categoría “deteriorable" se supone que "depó¬ 
sito” va seguido por un campo booleano que advierte si está o no 
estropeada (tenga en cuenta que esto es sólo un ejemplo...) 

He aquí tres posibles asignaciones significativas: una hipoté¬ 
tica VAR prod del tipo "producto" recién definido: 

prod.almac.codigma: = 123 
prodcat: = confec 
prodehaqueta: = 150.000. 

Por último, se podría imaginar un ARRAY de elementos del 
tipo producto: 

VAR inventar:ARRAYE1..2003 0F producto 

y localizar con inventar [i], depósito (o parecidos) un campo del 
i-ésimo producto 

Veamos rápidamente tipo SET (conjunto) que permite for¬ 
mar conjuntos de datos. La sintaxis usa las palabras reservadas 
SET OF seguidas por un tipo que en Pascal sólo puede ser esca¬ 
lar o sub-rango. 

Una vez definido un tipo SET se pueden hacer en él una serie 
de operaciones de unión de conjuntos (+), intersección (*), sus¬ 
tracción (-, consistente en quitar del primero todos los elementos 
que también son del segundo). Las comparaciones, además de 
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con = y O (cuyo significado es obvio), se pueden hacer con <= 
o con >=, que significan inclusión. Veamos un ejemplo: 

TYPE personajes^(lobo,cabra,coliflor,campesino); 

brigada=SET OF personajes; 

-VfiR barca,orillizq,ori¡lder:brigada¡ 


orillizq:=orillizq+barca; 

IF (lobo IN orillizq) AND (cabra IN oqllizq) THEN ... 

El programa es capaz de ofrecernos el momento en que al 
arribar la barca a la orilla izquierda se puede producir una situa¬ 
ción delicada simulada por la operación unión y el sucesivo aná¬ 
lisis de la situación; (lobo IN orillizq) restituye el valor booleano 
TRUE si en el conjunto ''orillizq" de "brigada” se encuentra el ele¬ 
mento lobo' y lo mismo con (cabra IN orillizq). Si ambas son cier¬ 
tas THEN las consecuencias son intuibles... 

La instrucción WITH sirve, en la fase de elaboración, para ma¬ 
nejar cómodamente los registros. 

Prácticamente no vamos a hablar del tipo FILE (flujo secuen- 
cial); sólo confirmarles que corresponde exactamente a lo que pa¬ 
rece y recomendarles manuales más especializados. Por otro lado 
nos urge tratar, aunque sea rápidamente, organizaciones más so¬ 
fisticadas de datos que sólo se pueden manejar con comodidad 
utilizando los lenguajes estructurados. 


Las estructuras dinámicas: pila (stack) y demás 

Al tratar los distintos tipos pascalianos hemos pasado por alto 
algunas cosas. En compensación vamos a hablar ahora, de forma 
abreviada, del tema quizá más delicado (¿después de la recursi- 
vidad? Depende de los gustos...) Por lo tanto, prepárense para uti¬ 
lizar su materia gris. 

Hasta hace un momento hemos estado viendo estructuras "es¬ 
táticas ", e¡g : decir, datos organizados de una forma más o menos 
compleja, pero que no cambia en el curso del programa Las es¬ 
tructuras dinámicas, que iremos viendo en este y los siguientes 
apartados, pueden ser: pilas (stack), códigos (code), listas y árbo¬ 
les; estos elementos hacen la delicia de los informáticos que pro¬ 
yectan compiladores e intérpretes, o incluso de aquellos que se 
ocupan de la Inteligencia Artificial. 

Las pilas ya las habíamos visto cuando tratamos la recursivi- 
dad, apuntando el hecho de que el stack tiene una importancia vi¬ 
tal en el Pascal. También dijimos que los mismos microprocesa- 
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dores adoptan una pila para guardar en ella el estado de sus pro¬ 
pios registros internos y la dirección de entrada de las subrutinas 
llamadas (una vez que se sale de ellas, es fácil recuperar todo lo 
que se había guardado temporalmente en la pila). 

Repetimos que una pila se define intuitivamente como un 
montón de elementos de los que sólo el último es "visible". En in¬ 
glés, una estructura como ésta es llamada '"memoria LIFO" (Last In 
First Out), último en entrar primero en salir, dado que siempre se 
extrae en primer lugar el último elemento almacenado (que esta¬ 
ba, por tanto, en la cima de la pila). 

Desde un punto de vista más riguroso, una pila consiste en 
una estructura de elementos homogéneos sobre la que se defi¬ 
nen dos operaciones fundamentales: PUSI-1 (literalmente "empuja") 
v POP (extrae), la una contraria a la otra. Con la primera se carga 
un elemento (o cualquier estructura, ya que a su vez podría estar 
compuesto de más elementos, como un array o un record) en la 
parte superior de la pila. Generalmente se le añade una estructu¬ 
ra llamada EMPTY que sirve para indicar si la pila está vacía o, si 
lo prefiere, "desinflada". 

El mecanismo de la pila es particularmente cómodo para el 
cálculo algebraico basado en la llamada notación polaca inversa 
(RPN - Reverse Polish Notation, utilizada, por ejemplo, en las cal¬ 
culadoras H. P.). Con i a RPN, una expresión de tipo (a + b)*(c - d) 
se escribiría: 

atb + ctd - * 

que no necesita paréntesis. En efecto, quedan sobreentendidas 
(como bien saben los usuarios de calculadoras de bolsillo 
Hewlett Packard) las dos reglas siguientes: ^ 

• al encontrar un dato lo cargamos en la pila (operación 
PUSH); 

• si se encuentra un operador aritmético se ejecuta la ope¬ 
ración correspondiente usando el dato situado en la cima 
de la pila (top) y áquel inmediatamente por debajo, 

consiguiente operación POP. 

En la expresión vista antes, la sucesión de acontecimientos 
se corresponde con la secuencia ilustrada en la figura 3. 

En este mismo mecanismo de la RPN se basa el lenguaje 
FORTH (un próximo volumen de la BBI permitirá a los curiosos 
profundizar en él). 

Sería interesante (pero lo dejamos como ejercicio para los - 
más avanzados) emular en Pascal o BASIC un sistema de cálculo 
similar. En cambio, nos tendremos que contentar con ver cómo se 
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M Figura 3—Sucesivos PUSH y POP de la pila necesarios en el cálculo 
de una fórmula aritmética con la notación polaca inversa (RPN). 


podría simular una pila en Pascal y en BASIC. En BASIC esto es 
indispensable en todos los casos prácticos, mientras el Pascal, que 
posee su propia pila, no nos permite construir, mediante una de¬ 
finición, un tipo-pila. Por lo tanto, nos tendremos que arreglar, en 
ambos casos, con un array. 

La realización se muestra en la figura 4. Como se puede ver, 
el puntero "punt” (en BASIC llamado PT) es, en realidad, un vulgar 
índice que, en el procedimiento PUSH, es incrementado antes de 
cargar el siguiente elemento del array, mientras que en el POP pri¬ 
mero se extrae el elemento y después se decrementa punt. En los 
dos ejemplos hay características no necesariamente universales, 
como la elección de elementos de tipo cadena en el array (la ca¬ 
dena, única riqueza verdadera del BASIC, puede resultar cómoda 
para cargar grupos de datos, pero en Pascal puede ser preferible 
el tipo-record) o el uso de una FUNCTION para el POP (alguien 
podría preferir que una misma variable "z" sirviese como bandera 
de carga para PUSH o de descarga para POP). Otra particularidad 
es haber escogido la función Ofñimits para señalar cualquier con¬ 
dición anómala del índice (a otros les habría gustado más que se 
distinguiera entre la situación de "empty" —vacía— y la de "over- 
ílow" —desbordamiento—). 

En cuanto al programa BASIC, el paralelismo con el Pascal 
nos ha estimulado a utilizar DEF FN, llegando al punto de poner 
el main debajo, precedido por la subrutina. 



Un paréntesis: ei dilema bottom-up/top-down 

Al habernos centrado en la creación de programas para el ma¬ 
nejo de la pila (stack) reutilizables en otro lugar, hemos dejado 
suelto el MAIN, constituido por un vacío encerrado entre los ter- 
minadores BEGIN y END. Esto nos ofrece la oportunidad de hacer 
una observación: no es del todo cierto que el Pascal se ciña ex¬ 
clusivamente a un planteamiento bottom-up (de abajo a arriba). Si 
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PROGRAM emulatlorpi la; 

CQNST maxpun:=200; 

VAR pila: ARRAY(1..ma xpunt > OF STRING; 
punt: INTEGER; 

PRDCEDURE pricpila; 

BEGIN punt:=0; 

END; 

FUNCTION offlimits: BOOLFAN; 

BEGIN 

IF punt=maxpunt THEN 
off 1imits:=TRUE; 

ELSE off1imits:=FALSE; 

END; 

PROCEDURE push(x:STRING); 

BEGIN 

IF NOT offlimits THEN 
BEGIN 

punt.-punt+1; pila(punt):=x 
END; 

END; 

FUNCTION pop: STRING; 

BEGIN 

IF NOT offlimits THEN 
BEGIN 

pop:=pila(punt); punt:=punt~l i 
END; 

END; 

BEGIN («-Main*) 

\ 

END. 


100 MAXP7-20G: DIM PIL.AÍ (MAXPT ) 

110 GOTO 500: REM SALTO AL INICIO DEL MAIN 
120 DEF FN 0FFLIMIT=(PT=0) OR <PT=MAXPT> 
130 REM PUSH 

140 IF DFFLIMIT THEN RETURN 
150 PT=PT+1: PILA$=XÍ 
160 RETURN 
170 REM POP 

180 IF OFFLIMIT THEN RETURN 
190 POP=PILAÍ(PT >: PT=PT-1 
200 RETURN 

500 REM INICIO DEL MAIN 


Figura 4.—Emulación de la estructura de pila: a) en Pascal y b) en 
BASIC. 
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lo desea, puede utilizar el top-down (de arriba a abajo). Esta es la 
demostración: 

PROGRAM arribaabajo; 

VAR lo,que,te,parezca:STRIN 65 
FUNCTIDN condiciBOOLEAN; 

BEGIN 

READLN (la) 

IF lo=’preg' THEN condic:=TRUE 

ELSE condic:=FALSE ^ 

ENE; 

PROCEDURE loseyo; 

BEGIN 

END; 

PROCEDURE 1osabestu; 

BEGIN 

END; 

PROCEDURE mannana (t no se puede usar ñ *) 

BEGIN 

END; 

FUNCTIDN pasadomannana; * 

END; 

BEGIN (» main t) 
loseyo;losabestu; 

IF condic THEN mannana 
ELSE pasadomannana 
END. 

El ejemplo es humorístico, pero pretende exponer cómo si de¬ 
terminamos con precisión la forma exacta en que tendrá que com¬ 
portarse el main y las piezas que lo componen (funciones y pro¬ 
cedimientos), será preciso, ante todo, el main mismo, mientras que 
su? módulos podrán estar vacíos. Dado que el compilador perma¬ 
nece indiferente ante procedimientos y funciones vacías, forma¬ 
das sólo por parejas BEGIN/END, se podrá expurgar exclusiva¬ 
mente el main. Luego haremos los refinamientos paso a paso, de¬ 
finiendo los diferentes módulos, con sus correspondientes com¬ 
probaciones, según se vaya completando el esquema. 

Como se puede intuir con el ejemplo, el desarrollo no es, en 
absoluto, banal: ha sido necesario insertar la función Condic para 
emular, mediante el teclado, un hecho que proporcionará alterna¬ 
tivas. Si todos los main se dejasen reducir a simples secuencias 
de procedimientos, inicialmente vacíos, sería estupendo, pero, por 
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desgracia, no suele pasar. En suma, en los casos reales la cone • 
xión entre módulos y programas principales es muy estrecha y 
el acercamiento progresivo del planteamiento top-down sólo con¬ 
templa un aspecto de la programación estructurada. 

Antes de acabar con las pilas debemos referirnos a otra es¬ 
tructura: la cola (queue en francés), que también aparece bajo las 
siglas i ¡FO (First ín First out, primero en entrar, primero en salir). 
Las funciones básicas de una cola (o lista de espera) se pueden 
definir como "pon en la cola" (''coloca") y "saca" ("sirve”). Se utiliza 
en los sistemas operativos para gestionar los almacenamientos in¬ 
termedios de entrada/salkia (donde se guardan los datos trans¬ 
mitidos o recibidos), y en los sistemas multiusuario para gestionar 
ecuánimemente las solicitudes de acceso (a impresora, disco rí¬ 
gido, etc.); también se podrían utilizar en un programa de simula¬ 
ción de hechos basados en la teoría de las colas (en estadística, 
por ejemplo). , 

La emulación de una cola, con el uso del habitual y servicial 
array, no es muy difícil. Bastará con dos índices-punteros, el pri¬ 
mero para la colocación de datos en la cima y el segundo para 
retirar los del final; esta vez ambas operaciones incrementan los 
punteros. Esto provoca un deslizamiento continuo hacia la parte 
alta de la memoria, que hace indispensable disponer de una or¬ 
ganización circular para el array. No se asusten, que no es mucho: 
bastara con obligar a la re-inicialización del puntero cuando lle¬ 
gue al valor máximo, mediante instrucciones del tipo: 

BEGIN 

puntuac;=puntuac+l¡ 

IF puntuac=pantuacitax THEN 
puntuac :=0 


Listas lineales 

Desde un punto de vista exclusivamete lógico, una lista lineal 

L es un conjunto de elementos dispuestos consecutivamente. Ge¬ 
neralmente se definen las funciones siguientes (con estos u otros 
nombres): 

• Primero (L), que nos da el primer elemento de L; 

• continuación (L), que nos da lo que queda de L después 
de haber quitado el que era primer elemento; 

• inserción de un nuevo elemento entre dos elementos cuaL 
quiera; 

• supresión de un elemento cualquiera. 
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No se trata, como en el caso de las matrices (arrays) de es¬ 
tructuras de acceso directo, pero de todas formas su carácter di¬ 
námico permite un manejo fácil, basado en una modificación con¬ 
tinua de los elementos que forman parte del conjunto. 

El punto característico de las listas (y, como se verá, de los 
árboles) es que no se trabaja con índices, sino con apuntadores, 
es decir, con parámetros, que, normalmente, forman parte del ele¬ 
mento y que "apuntan" al siguiente. Se habla de estructuras en "ca¬ 
dena", En la figura 5 se pone en evidencia el juego de apuntado¬ 
res necesario para insertar y para suprimir un elemento. 

El típico ejemplo de lista lineal es un 'texto, entendido como 
un conjunto de líneas (o palabras) en el que se pueden insertar o 
suprimir líneas (o palabras) en el que se pueden insertar o supri¬ 
mir líneas (o palabras). Análogamente, los sectores de un disco a 



CABEZA 



b) 


C) 



CABEZA 


QpOPY, 


PLUtO 


HORACIO 


'ATO DONALI 



M Figura 5.—a) Esquema de la organización de una lista lineal. Por nor¬ 
ma, el primer puntero mira hacia la "cabeza" de la lista. En b) se ilus¬ 
tra la inserción de un nuevo elemento. Manejando adecuadamente los pun¬ 
teros se puede insertar un nuevo elemento en cualquier sitio, c) Por últi¬ 
mo, en d) tenemos ¡a eliminación de un elemento: es suficiente con cam¬ 
biar un puntero. 
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menudo están dispuestos en forma de lista, para permitir una ges¬ 
tión dinámica del espacio. , , , r 

En los lenguajes estructurados como el Pascal (por no hablar 
de Modula 2 o Ada) cualquier elemento de una lista esta com¬ 
puesto por dos campos: el campo del valor y el campo del apun¬ 
tador (pointer). El apuntador es un tipo muy abstracto, En efecto, 
no se dice cómo está representado "materialmente : ¿será un ín¬ 
dice entero?, ¿un código? No se sabe: depende de la implemen- 
tación De todas formas, no está de más saber que, en la totalidad 
de ios casos prácticos, se trata de la dirección del dato hacia el 
cual "apunta", En Pascal se usa la siguiente definición: 

VAR apunt;lelemente; 

donde la flecha (que también es el símbolo de exponenciación, 
,a menudo sustituido por el acento circunflejo'?') indica que apun 
es un tipo-pointer que apunta hacia “elemento . Un valor particu¬ 
lar del apuntador es NULO (NIL), que significa que apunta hacia 
ninqún sitio. Sirve para las listas vacías o para señalar el final v el 
último elemento tiene un apuntador NULO). Veamos cómo se pue¬ 
de definir (recursivamente) una lista de palabras: 

TVPE apunt:{elemento; 
el efflentD=RECORD 

valor:STRIN6; 

continuaejon:{elemento; 

END; 

Vale la pena observar que éste es el único caso del Pascal 
en el que un "elemento" es referido antes de que esté completa 
su definición. El tipo "lista" está definido como un apuntado): hacia 
"elemento" que, a su vez, es un registro formado por los campos 
“valor" y “continuación" —que apunta al siguiente (obviamente 
los campos de datos podrían ser más de 1, lo mismo que los apun¬ 
tadores para listas más complejas o árboles). _ 

En la figura 6 tenemos: el listado del programa que contiene 
procedimientos en Pascal para el manejo de una lista lineal de ca¬ 
racteres (6a) y su equivalente en BASIC (6b): en el segundo caso 
nos las hemos tenido que arreglar por fuerza con dos vectores, el 
de los valores y el de los apuntadores 

En vista de que estos temas serán más detalladamente trata¬ 
dos en un próximo libro referente al manejo de datos, nos limita¬ 
mos a dos notas indispensables sobre el tipo pointer: 

• un elemento de la lista se especifica con una instrucción 
del tipo pttvalor; 
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PRQGRfiM 1istalineai; 

TYPE list3=felenentu; 
eles>ento=RECDRD 

valor:CHAR; 
contin:lista 
END; 

FUNCTION primeroía:lista):CHAR; 

BEGIN 

priuero:=ai.valor¡ 

END **■» 

FUNCTION sucesor(a¡lista):lísta; 

BE6IN 

sucesoria!.contin 
END 

FUNCTION emptv(a:1lsta>:BOOLEAN; 

BEGIN 

IF a:=NIL THEN 
empty:=TRUE 
ELSE 

empty:=FALSE 

END; 

FUNCTION inser(c:CHAR;a:lista)¡lista; 

VAR pt:iista; 

BEGIN 
new(pt); 
ptt.valor:=c; 
ptf.contin=a; 
inser:=pt 
END; 

FUNCTION busca(c:CHftR;a:lista)¡lista; 

(* da el primer elemento que coincide con c 1) 
VflR ene¡BOOLEAN; 

BEGIN 

ene: =FAL'SE; 

WHILE NOT ene AND (aONIL) DO 
IF c=af.valor THEN ene:=TRUE 
ELSE a:=contin(a); 
busca:=a 
END; 

END; 

BEGIN (J mairi *) 

END. 
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100 DIM LISTñí<200),SEG(200):5DTD1000 
150 DEF FN PRItií (L) =LISTAt (L) 

200 DEF FNSUCC(L)=SEG(L) 

250 DEF FNEMPTYÍD=L=0 

300 REM CREACION DE NUEVO ELEMENTO 

310 REM CON RESULTADO EN X 

320 LIB=LIB+1:REM NUEVO PUESTO LIBRE 

330 X=LIB 

340 RETURN 

350 REM 

390 REM EMULACION DE LA FUNCION 
400 REM INSERí(C$:CADENA;Ll:LISTA) 

410 REM RESULTADO 

420 GOSUB 300¡REM EMULA LA new(pt) 

430 LISTA»(X)=CÍ:SE6(X)=L1¡L2=X 
440 RETURN 
450 REM 

480 REM EHULAC. DE soppress(L:LISTA) 

490 REM RESULTADO EN L 
500 L=FNSUCC(L) 

510 RETURN 
520 REM 

570 REM EMULAC. DE BUSCA (C*¡CADENA;Ll:LISTA) 

580 REM RESULTADO EN L2 

590 REM B=VARIABLE IPSEUDO) LOCAL 

600 B=-l:L2=L1 

610 IF L2O0 AND B THEN 640 

620 IF LISTA»(L2)=C» THEN B=0:G0T0 610 

630 L2=FNSUCC(L2):G0TQ 610 

640 RETURN 

1000 REM INICIO MAIN 

.(a placer). 


’ Figura 6—Fundones típicas para el tratamiento de una lista lineal, 
en Pascal (a) y en BASIC (b). 


• la función new(pt) dada por el Pascal sirve para crear un 
apuntador pt, o sea, para dejar espacio cada vez que se in¬ 
serta un nuevo elemento (así se abrirá e intercalará un es¬ 
pacio en memoria). 
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Con referencia a las funciones de la figura 6, recuerden que 
una lista es localizada apuntando a su primer elemento, lo que su¬ 
pone que, recorriéndola hacia adelante, "se pierden" los elemen¬ 
tos barridos, Si no queremos que esto suceda, será necesario uti¬ 
lizar dobles apuntadores (listas bidireccionales). Finalmente, hay 
que decir que, en el programa de la figura 6, la función-lista Inser 
añade un nuevo carácter "c" a la cabeza de la lista "a", por lo que 
si quiere una inserción intermedia deberá usar previamente la fun¬ 
ción Busca. 

Otra laguna es el borrado, pero llenarla es sencillo. Utilizando 
siempre un apuntador auxiliar (pt, por ejemplo), como en la inser¬ 
ción, la cancelación del elemento que sigue a pt se hace con una 
sola instrucción: 

Ptf. contin: = ptt contin, contin. 

Efectivamente, en el segundo miembro se tiene el desplaza¬ 
miento de dos elementos y el apuntador resultante es asignado 
al primer miembro, saltándose así el elemento intermedio, 


Trepar a los árboles 

El ejemplo visto en la figura 6 justifica en parte el motivo que 
indujo a Wirth a no incluir el tipo cadena ni siquiera en el Modu¬ 
la 2: en efecto, una vez definida como lista de CHAR, una cadena 
se construye y se manipula con gran facilidad 

Otras estructuras de datos dinámicas son las listas bidireccio¬ 
nales y las circulares: las primeras dotadas de dos apuntadores 
por elemento, de los que uno apunta al sucesor y el otro al pre¬ 
decesor, y las segundas caracterizadas porque el apuntador del 
último elemento mira al primero (no hay ningún apuntador NIL). 
Estas listas unen a las ventajas ya vistas —borradas e inserciones 
fáciles— la del barrido secuencial; por ejemplo, si queremos man¬ 
tener un cierto orden cada vez que se añade un elemento, en una 
lista ordenada según un criterio, no será necesario recorrer la lis¬ 
ta desde el principio, sino que basta ir desde donde estemos has¬ 
ta el punto en que el elemento nuevo tenga que insertarse, asig¬ 
nándole entonces el código intermedio correspondiente. 

El árbol (tree, en inglés) nace también como estructura por 
esta exigencia, pero posee otras muchas ventajas y aplicaciones. 

El árbol constituye un conjunto organizado en sentido jerár¬ 
quico, y está generalmente "invertido", o sea, representado con el 
tronco para arriba: su vértice, llamado "raíz", está arriba, mientras 
que las ramificaciones están hacia abajo. En conjunto, un árbol es 
un “grafo", es decir, un conjunto de nudos unidos por ramas. De 
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cada nudo parten ramas que se'dirigen ("apuntan") a nudos de ni¬ 
vel inferior. Usando una terminología botánica, los nudos termina¬ 
les se llaman "hojas". A veces también se usa una nomenclatura 
de tipo genealógico, y en este caso se hablará de nudos "padre" 
y nudos "hijo". Evidentemente, una estructura de datos arbores¬ 
cente también se puede utilizar para representar un auténtico ár¬ 
bol genealógico: en la figura 7 vemos el pedigree de una hipoté¬ 
tica generación de perros de raza. Esto mismo vale para las cla¬ 
sificaciones por géneros o especies, en las ciencias naturales, 
en el archivo de una biblioteca o en un almacén de piezas de 
recambio. 

Un típico caso informático es el constituido por la organiza¬ 
ción en árbol de los sistemas de gestión de archivos (adoptado 
sobre todo en el sistema operativo UNIX de AT&T, pero también 
en el ProDOS del Apple Ilc/IIe y en el MS DOS del PC IBM y com¬ 
patibles). 

Seguramente es la flexibilidad de los árboles, lo que prefie¬ 
ran los informáticos: podemos ir desde la jerarquía top-down en 
los programas para valoración de los movimientos de un juego 



M Figura 7 —Una estructura de datos en árbol invertido podría muy 
bien representar árboles genealógicos , como los pedigrees de los 
perros de raza... 
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(ajedrez, damas, etc.) a la arquitectura de compiladores, por no ha¬ 
blar de la Inteligencia Artificial, sector donde se les considera 
como a reyes. 

En la clasificación se habla de niveles (un nudo hijo es de ni¬ 
vel inferior al de su padre) y de orden (número máximo permiti¬ 
do de ramas) definiéndose como "sub-árbol" todo árbol que ten¬ 
ga como raíz un nudo distinto al del cabeza de la serie (raíz prin¬ 
cipal). 

Nosotros nos vamos a limitar a una categoría particular, muy 
importante, dentro de los árboles: los árñeles binarios (aquellos 
en los que el orden es dos). Cada nudo tiene, por tanto, como mu¬ 
cho, dos hijos, distinguidos habitualmente como izquierdo y de¬ 
recho. El árbol binario es útil por su mayor sencillez. Árboles con 
un orden mayor que dos se pueden reducir con las adecuadas re¬ 
glas a árboles binarios. 

Estas son las operaciones básicas que definen a un árbol 
binario. 


• acceso, 

• creación, 

• verificación. 

El acceso consiste en tres operaciones de .lectura: raíz, hijo 
derecho e hijo izquierdo. La creación se realiza partiendo de dos 
subárboles e introduciendo una raíz nueva. La tercera función 
comprueba si un árbol está vacío o no. 

De forma análoga a lo visto para las listas, un árbol binario se 
puede simular con tres arrays asociados: el vector de los valores 
(nudo) y los de jos punteros izquierdo y derecho (ramas). En 
BASIC ésta es la única implementación posible, mientras que en 
Pascal el tipo pointer sirve mucho mejor para este fin. 


Visitar un árbol 

Una importante noción al emplear los árboles es la llamada 
técnica de la 'visita", que describe las posibles modalidades para 
recorrer todos sus nudos. Con las listas se puede proceder sólo 
en dos sentidos; ahora son tres las posibilidades. Si llamamos R, I, 
D, respectivamente, a la raíz y a los hijos izquierdo y derecho, las 
secuencias de visita son: 

• visita pre-orden: R-I-D, 

• visita post-orden I-D-R, 

• visita en-orden: I-R-D. 


Refiriéndonos a la figura 8, y teniendo en cuenta que un nudo 
que no sea una hoja se identifica por el subárbol del que es raíz, 
las tres visitas dan lugar a las siguientes sucesiones: 

• pre-orden: A-B-D-E-C-F-H-I-G; 

• post-orden: D-E-B-H-I-F-G-C-A; 

• en-orden: D-B-E-A-H-F-I-C-G. 

Para entendernos meior: en esencia por "visita 1 se entiende 
el alcanzar de forma consecutiva determinados nudos, respetan 
do unas i colas dadas (según la técnica de visita); en algunas oca¬ 
siones será necesario, antes de llegar a un nudo en concreto, ba¬ 
rrer en profundidad otros nudos, "dejándolos en reserva . Hacién¬ 
dolo prácticamente, primero hay que salir de la raíz, después de 
lo cual, por ejemplo en una visita post-orden, tendremos que ba¬ 
jar hasta la hoja D (Fig. 8) antes de empezar; una vez recorrido el 
subárbol D-E-B pasaremos (¡sin "asumirla"!) por la raíz y desde ella 
bajaremos a H para volver a empezar la visita. Dejar en reserva 
algo supone, en este caso, la utilización de una pila (stack), posi¬ 
blemente automática... . . 

Una aplicación interesante de los árboles bínanos y sus co¬ 
rrespondientes visitas la tenemos en las expresiones algebraicas. 
Refiriéndonos a la figura 8b), un árbol que represente en sus ho¬ 
jas operadores aritméticos y datos puede dar lugar a tres notacio¬ 
nes: 


NOTACION 

prefija 

postfija 

infija 


VISITA 

pre-orden 

post-orden 

en-orden 


RECORRIDO 

*+*5 3 2-84 
5 3*2 + 8 4 - * 
(5*3 + 2)*(8 - 4) 


La tercera es la ordinaria, mientras que la post-fija es la RPN ya 
vista. En la última línea hemos puesto paréntesis sólo para recor¬ 
dar que el resultado se va calculando sin priondades, será bo, 
como en las otras dos visitas: 


Recursividad: ventajas prácticas 

En la figura 9 presentamos un programa en Pascal completa¬ 
do esta vez con un pequeño main didáctico, utilizado para demos¬ 
trar las tres técnicas de visita en el caso de la expresión algebrai¬ 
ca vista en la figura 8b). La definición del tipo algbin es evidente: 
con respecto a la lista, se trata solamente de un puntero mas. Tam¬ 
bién la FUNCTION Crea tiene una perfecta analogía con la inser 
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MSj Figura 8.—En a) tenemos un árbol binario genérico y en b) el 
MíM rrespondiente a la representación de una expresión algebraica 
ambos casos se pueden realizar las tres técnicas base de "visita" 

a) se pueden apreciar varios subárboles (de orden>l) mientras que 

b) la visita en-orden está representada con lineas de trazos para las b, 
das al hijo izquierdo" y líneas conünuas para la visita hijo-padre-hijo. 




PR06RAM expresalg; 

TYPE algbín=*eleraentoi 
elenento=RECORD 

valor:STRING; 
hijoizq:algbin; 
hijodenalgbin; 

END; 

VAR expres:algbin; 

FUNCT10N crea(val:STRINB;hizq,hdersalqbin):alQQ 
VAR pt:algbin; 

BEEIN 
new(pt); 
ptt.valor:=val; 
pti.hijoizq:=hizq; 
pt^.hijoder:=hder; 

crea:=pt¡ 

END; 

PRDCEDURE preorden(a:alqbin); 

BEEIN 

IF aONIL THEN 
BEEIN 

NRITE (ai.valor); 
preorden(al.hijoizq); 
preorden(af.hijoder); 

END 

END; 

PROCEDURE postDrdenla:algbin); 

BEGIN 

IF aONIL THEN 
BEEIN 

postorden(af.hijoizq); 
postordentai.hijoder); 

NRITE (a!.valor) 

END 

END; 

PROCEDURE enorden!a:algbin); 

BEGIN 

IF aONIL THEN 
BEEIN 

enorden <al.bijoizq); 

NRITE (ai.valor); 


enordenfai.hijoder); 
END 


END; 

BEGIN (* aain t) 

expres:=crea(’t\creaf’+’, C rea(’l’, 

crea(’5’,NIL,NIL), 

crea(’3’, NIL, NIL)), crea )'2\NIL, NIL)), 
crea!’-’, creaCB’.NIL.HIL), 
crea(’4’,nil,nil)))¡ 
preorden íexpres);WRITELN; 
postorden(expres);WRITELN; 
enorden(expres) 

END. 


' Fl S. Ura , 9 ~ Llstado de! programa Expresalg, que comprende la fun- 
ción de creación de un árbol binario y la de los tres tipos de visita 
En el mam se genera el árbol de una expresión algebraica, y se realiza 
su visita por los tres modos, imprimiendo, para su verificación, las expre¬ 
siones correspondientes. H 


del programa de tratamiento de listas de la figusa 6, aparte de te¬ 
ner dos apuntadores en lugar de uno. Después de esto, sugeri- 
mos dar un vistazo al main. en la parte introductoria, donde se- 
crea el árbol de la figura 8b), las hojas se definen en las expre¬ 
siones que contienen dos apuntadores NIL, mientras que para los 
demás elementos Crea sigue el mecanismo de la visita pre-orden 
adoptada como la más natural. 

Para ayudar a comprender este intrincado parentesco, les su¬ 
gerimos empezar por escribir de nuevo la visita pre-orden de la 
figura 8b), insertando esta vez los paréntesis necesarios para evi¬ 
denciar los distintos subárboles: 

* (+ (* 5 3) 2) (- 8 4) 

Una vez llegados aquí, ya sólo se trata de un juego de pa- 
ciencia. recurrir a la función Crea añadiendo los elementos que 
definen las cadenas en Pascal y las comas que separan los tres 
parame ros de Crea, sin olvidar todas las hojas, como 5 que son. 
traducidas en Crea según ('5', NIL, NIL). 

Notará inmediatamente la comodidad típica del Pascal en las 
lamadas anidadas de las funciones (sólo son necesarios unos po¬ 
cos paréntesis), pero esto no es nada con respecto a la potencia 
expresiva de las auto-invocaciones recursivas de los tres proce¬ 
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dimientos Preorden, Postorden e Inorden: la autoinvocación fun¬ 
ciona, ya sea para el hijo izquierdo o el derecho, mientras que el 
subárbol-parámetro no sea NIL. 

Tenemos que ''creernos' 1 todo lo que se ha dicho sobre la re- 
cursividad y admirar el hecho de que, en el ejemplo en cuestión, 
las tres técnicas de visita se diferencien sólo por la sucesión con 
que el WRITE (para la impresión del valor del nudo alcanzado) y 
las instrucciones relativas a las ramas izquierda y derecha se pre¬ 
sentan. 

Una aplicación muy interesante de los árboles binarios es con 
los conjuntos de datos “verdaderos y propios". El método permite 
mantener un ordenamiento de una forma sencilla y suficientemen¬ 
te veloz. El algoritmo consiste en crear una arborescencia inser¬ 
tando sistemáticamente los datos inferiores a la raíz en el subár¬ 
bol izquierdo, y en el derecho, los datos superiores. Este proceso 
equivale al método de bisección (algoritmo utilizado normalmen¬ 
te para el ordenamiento y la búsqueda en el array): se opera pri¬ 
mero con la mitad, luego con la mitad de la mitad y así sucesiva¬ 
mente, por lo que da mejores resultados que las listas, como ya 
hemos dicho. De todas formas, para poner simplemente un ejem¬ 
plo, suponga que van llegando a un árbol binario, vacío en prin¬ 
cipio, los valores siguientes: 17, 12, 5, 80, 10, 35, 8, 6, 11, 94, 27, 24, 
20, 48. Si ha entendido cómo funciona el procedimiento, intente 
construir el árbol binario, y después compárelo con el de la figura 
10, donde al lado de cada nudo figura entre paréntesis el orden 
de llegada. Una pregunta (será la última): ¿cuál de los tres tipos 
de visita —pre-post y en-orden— proporciona una salida ordena¬ 
da de los datos en un árbol binario semejante? 

Veamos el listado directamente: 

\ 

PROGRAM inserción; 

TYPE algbin=fel ementa; 
ele«ento=RECORD 

postcp:INTE6ER; 
ciudad:STRING; 
hijiz,hijder:algbin; 

END; 

VfiR albcp:algbin;cp:INTE6ER:ciu:STRING; 

FUNCT10N crea.... 

(* parecida a la de la fig.8 *) 

FUNCT1DN enorden... 

(I parecida a la de la fig.B *) 

END; 


FUNCTION inser(x:INTEGER;y:STRINB;a:algbin):algbin; 

BEGIN 

IF a=NIL THEN 
ins:=crea(x,y,NIL,NIL) 

ELSE 

IF x<=aí.posteo THEN 
inser:=inser(x,y,a!.hijiz) 

ELSE 

inser:=inser(x,y,ai.iqder) v. 

END; 

BEGIN (* main t) 
al bcp: =NH; 

REPEfiT 

READLN <cp,ciu):inser(cp,ciu,albep); 

UNTIL cp=0 
enorden (albep); 

END. 

Ha sido imaginada la creación con la visita de control de una 
base de datos de los cp (códigos postales) con las correspondien¬ 
tes ciudades; en consecuencia, el registro ahora contiene dos va¬ 
lores: cp y ciudad. Después, la parte dejada oh reserva con los 
puntitos es prácticamente idéntica a la de la figura 9, excepto pe¬ 
queñas variantes que tengan que ver con la nueva estructura del 
tipo algbin. 

Una vez más, la FUNCTION Inser es elocuente. No es más que 
la traducción formalizada y recursiva del algoritmo descrito: si el 
árbol está vacío crea la raíz, si no Inser(ta) la nueva pareja (cp y 
ciudad) leída por el teclado. Advierta que, gracias al mecanismo 
recursivo, la condición IF también nos hace salir de Inser, por lo 
que el último elemento alcanzado ha encontrado un lugar. En efec¬ 
to, Crea (x, y NIL, NIL) se adapta justamete a cada nuevo nudo, 
raíz de momento sin hijos, pero potencialmente prolífica. Esto es 
lo que significa una estructura dinámica. 

Para terminar, la última línea del main nos revela en seguida 
que la visita Enorden corresponde, obviamente, a la definición 
misma de la base de datos ordenada por el árbol binario. 

Una breve despedida 

Alguien se preguntará: ¿hay un programa BASIC equivalente 
a éste? Desgraciadamente, esta vez no hay ni siquiera reflejos de 
todos los fuegos artificiales-recursivos del Pascal. Los caminos a 
recorrer podrían ser los siguientes: 



Figura 10.—La Figu,a ilustra cómo se "cuelgan" de un árbol binario 
valores dispuestos en orden. Los números externos, entre parénte¬ 
sis, indican el orden de llegada, según la sucesión mencionada en el texto. 


• implantar, según ya hemos sugerido en otro lugar, una 
pseudo pila y "engancharla 1 ' a las llamadas recursivas; 

• en general es más sencillo emular la recursión con la ite¬ 
ración, y, en este caso específico, el truco consiste, a gran¬ 
des rasgos, en insertar los adecuados punteros. 

Pero ambas explicaciones exceden los límites de este libro. 
Esperamos que aquellos que no tengan la paciencia o el tiempo 
necesarios para profundizar un poco más en estos temas, por lo 




menos habrán aprendido algo. Queremos puntualizar algunas 
cuestiones antes de despedirnos: 

• últimamente ha remitido un poco la polémica con los es- 
tructuralistas, e incluso, en los libros más recientes sobre 
lenguajes de programación, podemos encontrar cierta per¬ 
misividad (en especial en el lenguaje C); 

• en el duelo BASIC-Pascal todavía domina (aunque por 
poco) el primero por dos motivos: el primero va ligado a 
la mayor cantidad de programasMesarrollados; el segun¬ 
do es la mayor flexibilidad del BASIC, sin las obligaciones 
tan formalizadas del Pascal, que, a veces, pueden parecer 
demasiado complicadas a los profanos; 

• la llegada de BASICs.estructurados supondría el triunfo in¬ 

mediato de los principios de la programación estructura¬ 
da: por ejemplo, en el SuperBASIC usado en el QL de Sin¬ 
clair, no falta prácticamente nada: construcción IF/ELSE (in¬ 
cluso mejor que la del Pascal, ya que tiene el terminador 
ENDIF, que evita ciertos problemas de los que ya habla¬ 
mos a su debido tiempo), FOR y REPEAT (con EX1T antici¬ 
pado de un bucle, cuya falta en Pascal es incómoda a ve¬ 
ces) y procedimientos y funciones con variables locales y 
parámetros. * 

Sin necesidad de esperar la muerte del BASIC tradicional 
—siempre anunciada, pero aún lejana—, hoy en día los cánones 
de la programación estructurada se imponen cada vez más: la gra¬ 
dual inclinación hacia instrumentos potentes y expresivos es, sin 
duda, sincera por parte de muchos BASICalistas empedernidos. 

Hablando en términos generales, esos cánones son la clari¬ 
dad y la precisión, pero la auténtica idea central es la íntima unión 
de la estructura de datos con los procedimientos (algoritmos). De¬ 
sarrollarla, incluso con los pobres instrumentos de los lenguajes 
tradicionales, es casi un deber; ofrece grandes ventajas y, a la vez 
que muchos dolores de cabeza, bastantes satisfacciones. 
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L problema de la construcción racional y 
bien organizada de un programa surgió 
bastante pronto en la historia de la infor¬ 
mática. La prisa por desarrollar una apli¬ 
cación por un lado y, por otro, ¡a anarquía 
de los programadores han provocado a 
menudo auténticos desastres, plasmados 
normalmente en la escasa legibilidad y la 
costosa manutención del software (por no hablar de los 
errores bug, más o menos difíciles de localizar). 

La programación estructurada nació precisamente 
con el fin de poner orden &n el caos, tratando de impo¬ 
ner un estilo y un planteamiento claros y metódicos, ba¬ 
sados en reglas simples y precisas 

Los lenguajes estructurados (de los que, en el ámbi¬ 
to de los ordenadores personales, el más conocido es el 
Pascal) son algo mucho más profundo y, a ¡a vez, más po¬ 
tente que unas simples estructuras de control. Fundamen¬ 
talmente, se trata de la subdivisión en bloques (en nive¬ 
les jerárquicos) y de la definición racional de ¡os tipos 
de datos. Se descubren así otros conceptos complejos, 
pero muy útiles, como ¡a recursividad. 

Basándonos en el Pascal, podremos entrar en la pro¬ 
gramación estructurada y conseguir, por lo menos, una 
estructuración mental que nos permita hacer un progra¬ 
ma como es debido. 
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